Mailing list for developers of the Equinox OSGi implementation

Jeff McAffer | 3 Dec 02:50

Re: org.eclipse.equinox.util bundle

Interesting. This is a friend (no pun intended) of the problem raised recently on the PMC mailing list. The idea of having whole bundles as "internal". By default I suppose that if a bundle only ever exports x-internal := true things then there is nothing interesting for anyone to depend on the bundle for so there is no real need to depend on the bundle at all and the idea of marking the bundle "internal" does not matter.

I am bummed by having another bundle that we have to ship and manage etc but if the code really is shared and used/useful across many bundles than having it actually shared is a good thing.

Jeff

Thomas Watson <tjwatson-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org

11/30/2007 05:43 PM

Please respond to
Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

To	Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>
cc
Subject	Re: [equinox-dev] org.eclipse.equinox.util bundle

equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org wrote on 11/30/2007 08:08:22 AM:

> Hi all,
>
> For the org.eclipse.equinox.util bundle:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=206151
> I have some comments/questions.
>
>
> 1. Can I change the name to the "org.eclipse.equinox.internal.util"
> and kept here only the classes that are needed for more than one bundle?

There is no precedence for doing this in Eclipse. But it does make some
sense to me. This would make it obvious that the whole bundle is
really just an internal implementation detail. What do others think?

>
> 2. Still we will keep the bundle in the equinox distribution or we will
> move the classes to the org.eclipse.equinox.common.jar in the future?

For now I think we should make all the packages internal and use
x-friends where appropriate for the other service bundles. In the
future it is possible that we could move the packages to common and
make them real API with no "internal" name in the package. But we
will not do that unless the gain is substantial (i.e. needed by a
large set of clients in the Eclipse community).

>
> Next week I will work on removing dependencies and some packages from
> the util bundle but I need decision about the packaging and naming
> prior finishing the work.
>
>
> -Pavlin

Thanks Pavlin. For now you should move the packages out
of the equinox.util into other bundles where appropriate and rename
the remaining packages to include "internal" in the name with
x-friends for the bundles that need the package.

A final decision on the symbolic name of the util bundle can
be made after the package restructuring.

Tom.
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

headers

Pavlin Dobrev | 3 Dec 10:33

Re[2]: org.eclipse.equinox.util bundle

Hi Jeff,

Should I rename org.eclipse.equinox.util packages to org.eclipse.equinox.internal.util or not. Some of the packages are used only by DS bundle in equinox distribution. Others are used for more than one bundle.

The nature of the packages used only from DS bundles are utilities - like thread pool, xml processing, io, common utilities for access to the framework structures etc.

In our FW implementation such utilities are packaged in one bundle putil

http://dz.prosyst.com/user-manuals/mBS_Equinox_Edition_2.0.0/framework/bundles/prosyst/system/putilfull/introduction.html similar to equinox.common bundle (license of PUTIL is EPL and the code is distributed with mBS Equinox Eddition). We want after including the code in Equinox to move our code to use donated one in order not to have duplication of the code. It will be strange other bundle to have a dependency with DS only for utility classes.

Now I work to remove as many as possible dependencies from util bundle but in some cases this will decrease performance (removing of thread pool) and increase used memory (remove usage of object pools). Do you think that this is the right way?

-Pavlin

>

Interesting. This is a friend (no pun intended) of the problem raised recently on the PMC mailing list. The idea of having whole bundles as "internal". By default I suppose that if a bundle only ever exports x-internal := true things then there is nothing interesting for anyone to depend on the bundle for so there is no real need to depend on the bundle at all and the idea of marking the bundle "internal" does not matter.

I am bummed by having another bundle that we have to ship and manage etc but if the code really is shared and used/useful across many bundles than having it actually shared is a good thing.

Jeff

Thomas Watson <tjwatson-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org

11/30/2007 05:43 PM

Please respond to

Equinox development mailing list <equinox-dev <at> eclipse.org>

To	Equinox development mailing list <equinox-dev <at> eclipse.org>
cc
Subject	Re: [equinox-dev] org.eclipse.equinox.util bundle

equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org wrote on 11/30/2007 08:08:22 AM:

> Hi all,

>

> For the org.eclipse.equinox.util bundle:

> https://bugs.eclipse.org/bugs/show_bug.cgi?id=206151

> I have some comments/questions.

>

> 1. Can I change the name to the "org.eclipse.equinox.internal.util"

> and kept here only the classes that are needed for more than one bundle?

There is no precedence for doing this in Eclipse. But it does make some

sense to me. This would make it obvious that the whole bundle is

really just an internal implementation detail. What do others think?

>

> 2. Still we will keep the bundle in the equinox distribution or we will

> move the classes to the org.eclipse.equinox.common.jar in the future?

For now I think we should make all the packages internal and use

x-friends where appropriate for the other service bundles. In the

future it is possible that we could move the packages to common and

make them real API with no "internal" name in the package. But we

will not do that unless the gain is substantial (i.e. needed by a

large set of clients in the Eclipse community).

>

> Next week I will work on removing dependencies and some packages from

> the util bundle but I need decision about the packaging and naming

> prior finishing the work.

>

> -Pavlin

Thanks Pavlin. For now you should move the packages out

of the equinox.util into other bundles where appropriate and rename

the remaining packages to include "internal" in the name with

x-friends for the bundles that need the package.

A final decision on the symbolic name of the util bundle can

be made after the package restructuring.

Tom.

_______________________________________________

equinox-dev mailing list

equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org

https://dev.eclipse.org/mailman/listinfo/equinox-dev

headers

James D Miles | 4 Dec 03:21

[prov] Version defaults for root IU

Is it allowed to have multiple versions of a root IU in a metadata repository?
I created 2 sdk IUs, version 3.4.0.v20071101-2000 and 3.4.0.v20071101-2001

When I run the directory app with either version specified I get the sdk installed.
When I don't specify the version I get this error
!MESSAGE Can't find a solution where both: Match[requiredCapability: org.eclipse.equinox.p2.iunamespace/sdk/[3.4.0.v20071101-2000,3.4.0.v20071101-2000]] and Match[requiredCapability: org.eclipse.equinox.p2.iunamespace/sdk/[3.4.0.v20071101-2001,3.4.0.v20071101-2001]] would be satisfied.

It seems that it should be selecting one of these as a default.

headers

Pascal Rapicault | 4 Dec 03:39

Re: [prov] Version defaults for root IU

It is possible and will be in 1.0. We have been using this functionality to
test M3 by having a repository containing the I-builds of the SDK
(http://download.eclipse.org/eclipse/testUpdates/, note that the refered
site currently only contains one version of the SDK because it is being
purged every week. It will contain multiple version next week when I builds
are being run every 4 hours).

The problem you are encountering is likely caused by limitations in our
resolver. It will be addressed in M5.

For context, do you have anything else in your repository? How / from what
did you generate the metadata?

Thx

PaScaL

                                                                                                                                                 
  From:       James D Miles <jdmiles@...>                                                                                                 

  To:         equinox-dev@...                                                                                                            

  Date:       12/03/2007 09:21 PM                                                                                                                

  Subject:    [equinox-dev] [prov] Version defaults for root IU                                                                                  

Is it allowed to have multiple versions of a root IU in a metadata
repository?
I created 2 sdk IUs, version 3.4.0.v20071101-2000 and 3.4.0.v20071101-2001

When I run the directory app with either version specified I get the sdk
installed.
When I don't specify the version I get this error
!MESSAGE Can't find a solution where both: Match[requiredCapability:
org.eclipse.equinox.p2.iunamespace/sdk/[3.4.0.v20071101-2000,3.4.0.v20071101-2000]]
 and Match[requiredCapability:
org.eclipse.equinox.p2.iunamespace/sdk/[3.4.0.v20071101-2001,3.4.0.v20071101-2001]]
 would be satisfied.

It seems that it should be selecting one of these as a default.
_______________________________________________
equinox-dev mailing list
equinox-dev@...
https://dev.eclipse.org/mailman/listinfo/equinox-dev

headers

Thomas Watson | 4 Dec 04:24

Equinox projects tagged for 3.4 I-Build

The map file has been updated for the following Bug changes:
+ Bug 44735. Unable to create platform lock file (ASSIGNED)
+ Bug 179619. Request for friendship: org.eclipse.core.filesystem (FIXED)
+ Bug 188304. Execution environment restricts access to org.w3c.dom sub packages (ASSIGNED)
+ Bug 207505. [registry] order in which registry events are sent vs. bundle dependencies (FIXED)
+ Bug 207847. Warnings in the log file when nl fragments for osgi bundles are present. (FIXED)
+ Bug 209344. [log] need an event adapter (FIXED)
+ Bug 209694. Equinox webstart launcher ignores interactive login splash handler (NEW)
+ Bug 210384. console is blocking in 3.3.1 (ASSIGNED)
+ Bug 210699. Moving AdapterFactory into the registry bundle (FIXED)
+ Bug 211289. osgi.services and osgi.util source bundles are broken (FIXED)
+ Bug 211295. equinox launcher source bundle is missing about.html (FIXED)
+ Bug 211823. HttpContextManager ArrayIndexOutOfBoundsException (ASSIGNED)

The following projects have changed:
org.eclipse.equinox.launcher.motif.hpux.ia64_32
org.eclipse.equinox.launcher
org.eclipse.equinox.log
org.eclipse.osgi.services
org.eclipse.equinox.executable
org.eclipse.osgi.util
org.eclipse.equinox.registry
org.eclipse.equinox.supplement
org.eclipse.equinox.common
org.eclipse.equinox.http.registry
org.eclipse.osgi.tests
org.eclipse.osgi

Tom

headers

James D Miles | 4 Dec 04:43

Re: [prov] Version defaults for root IU

I ran the metadata generator twice against the sdk and changed the rootVersion for the second run. I didn't check the result for correctness but it worked when each version was specified.

Pascal Rapicault <Pascal_Rapicault-G1DYhSM1WHTQT0dZR+AlfA@public.gmane.org>

12/03/2007 08:39 PM

Please respond to
Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

To	Equinox development mailing list <equinox-dev <at> eclipse.org>
cc
Subject	Re: [equinox-dev] [prov] Version defaults for root IU

It is possible and will be in 1.0. We have been using this functionality to
test M3 by having a repository containing the I-builds of the SDK
(http://download.eclipse.org/eclipse/testUpdates/, note that the refered
site currently only contains one version of the SDK because it is being
purged every week. It will contain multiple version next week when I builds
are being run every 4 hours).

The problem you are encountering is likely caused by limitations in our
resolver. It will be addressed in M5.

For context, do you have anything else in your repository? How / from what
did you generate the metadata?

Thx

PaScaL

From: James D Miles <jdmiles-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

To: equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org

Date: 12/03/2007 09:21 PM

Subject: [equinox-dev] [prov] Version defaults for root IU

Is it allowed to have multiple versions of a root IU in a metadata
repository?
I created 2 sdk IUs, version 3.4.0.v20071101-2000 and 3.4.0.v20071101-2001

When I run the directory app with either version specified I get the sdk
installed.
When I don't specify the version I get this error
!MESSAGE Can't find a solution where both: Match[requiredCapability:
org.eclipse.equinox.p2.iunamespace/sdk/[3.4.0.v20071101-2000,3.4.0.v20071101-2000]]
and Match[requiredCapability:
org.eclipse.equinox.p2.iunamespace/sdk/[3.4.0.v20071101-2001,3.4.0.v20071101-2001]]
would be satisfied.

It seems that it should be selecting one of these as a default.
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

headers

Thomas Watson | 4 Dec 15:17

Re: Re[2]: org.eclipse.equinox.util bundle

At this point the packages should be renamed to have "internal" in the package name. In the future we can look at moving the packages to true API packages.

Tom

Pavlin Dobrev ---12/03/2007 03:34:29 AM---Hi Jeff,

From:	Pavlin Dobrev <p.dobrev-gIMOvL9Iw+9BDgjK7y7TUQ@public.gmane.org>
To:	Equinox development mailing list <equinox-dev <at> eclipse.org>
Date:	12/03/2007 03:34 AM
Subject:	Re[2]: [equinox-dev] org.eclipse.equinox.util bundle

Hi Jeff,

Should I rename org.eclipse.equinox.util packages to org.eclipse.equinox.internal.util or not. Some of the packages are used only by DS bundle in equinox distribution. Others are used for more than one bundle.

The nature of the packages used only from DS bundles are utilities - like thread pool, xml processing, io, common utilities for access to the framework structures etc.
In our FW implementation such utilities are packaged in one bundle putil
http://dz.prosyst.com/user-manuals/mBS_Equinox_Edition_2.0.0/framework/bundles/prosyst/system/putilfull/introduction.html similar to equinox.common bundle (license of PUTIL is EPL and the code is distributed with mBS Equinox Eddition). We want after including the code in Equinox to move our code to use donated one in order not to have duplication of the code. It will be strange other bundle to have a dependency with DS only for utility classes.

Now I work to remove as many as possible dependencies from util bundle but in some cases this will decrease performance (removing of thread pool) and increase used memory (remove usage of object pools). Do you think that this is the right way?

-Pavlin

>

Interesting. This is a friend (no pun intended) of the problem raised recently on the PMC mailing list. The idea of having whole bundles as "internal". By default I suppose that if a bundle only ever exports x-internal := true things then there is nothing interesting for anyone to depend on the bundle for so there is no real need to depend on the bundle at all and the idea of marking the bundle "internal" does not matter.

I am bummed by having another bundle that we have to ship and manage etc but if the code really is shared and used/useful across many bundles than having it actually shared is a good thing.

Jeff

Thomas Watson <tjwatson-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Sent by: equinox-dev-bounces <at> eclipse.org
11/30/2007 05:43 PM

Please respond to

Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

To	Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>
cc
Subject	Re: [equinox-dev] org.eclipse.equinox.util bundle

equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org wrote on 11/30/2007 08:08:22 AM:

> Hi all,
>
> For the org.eclipse.equinox.util bundle:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=206151
> I have some comments/questions.
>
>
> 1. Can I change the name to the "org.eclipse.equinox.internal.util"
> and kept here only the classes that are needed for more than one bundle?

There is no precedence for doing this in Eclipse. But it does make some
sense to me. This would make it obvious that the whole bundle is
really just an internal implementation detail. What do others think?

>
> 2. Still we will keep the bundle in the equinox distribution or we will
> move the classes to the org.eclipse.equinox.common.jar in the future?

For now I think we should make all the packages internal and use
x-friends where appropriate for the other service bundles. In the
future it is possible that we could move the packages to common and
make them real API with no "internal" name in the package. But we
will not do that unless the gain is substantial (i.e. needed by a
large set of clients in the Eclipse community).

>
> Next week I will work on removing dependencies and some packages from
> the util bundle but I need decision about the packaging and naming
> prior finishing the work.
>
>
> -Pavlin

Thanks Pavlin. For now you should move the packages out
of the equinox.util into other bundles where appropriate and rename
the remaining packages to include "internal" in the name with
x-friends for the bundles that need the package.

A final decision on the symbolic name of the util bundle can
be made after the package restructuring.

Tom.
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

headers

Pavlin Dobrev | 4 Dec 19:55

Re[4]: org.eclipse.equinox.util bundle

Hi Tom,

All requested changes are performed in the CVS. Can you verify?

-Pavlin

>

At this point the packages should be renamed to have "internal" in the package name. In the future we can look at moving the packages to true API packages.

Tom

Pavlin Dobrev ---12/03/2007 03:34:29 AM---Hi Jeff,

From:

Pavlin Dobrev <p.dobrev-gIMOvL9Iw+9BDgjK7y7TUQ@public.gmane.org>

To:

Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

Date:

12/03/2007 03:34 AM

Subject:

Re[2]: [equinox-dev] org.eclipse.equinox.util bundle

Hi Jeff,

Should I rename org.eclipse.equinox.util packages to org.eclipse.equinox.internal.util or not. Some of the packages are used only by DS bundle in equinox distribution. Others are used for more than one bundle.

The nature of the packages used only from DS bundles are utilities - like thread pool, xml processing, io, common utilities for access to the framework structures etc.

In our FW implementation such utilities are packaged in one bundle putil

http://dz.prosyst.com/user-manuals/mBS_Equinox_Edition_2.0.0/framework/bundles/prosyst/system/putilfull/introduction.html similar to equinox.common bundle (license of PUTIL is EPL and the code is distributed with mBS Equinox Eddition). We want after including the code in Equinox to move our code to use donated one in order not to have duplication of the code. It will be strange other bundle to have a dependency with DS only for utility classes.

Now I work to remove as many as possible dependencies from util bundle but in some cases this will decrease performance (removing of thread pool) and increase used memory (remove usage of object pools). Do you think that this is the right way?

-Pavlin

>

Interesting. This is a friend (no pun intended) of the problem raised recently on the PMC mailing list. The idea of having whole bundles as "internal". By default I suppose that if a bundle only ever exports x-internal := true things then there is nothing interesting for anyone to depend on the bundle for so there is no real need to depend on the bundle at all and the idea of marking the bundle "internal" does not matter.

I am bummed by having another bundle that we have to ship and manage etc but if the code really is shared and used/useful across many bundles than having it actually shared is a good thing.

Jeff

Thomas Watson <tjwatson-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org

11/30/2007 05:43 PM

Please respond to

Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

To	Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>
cc
Subject	Re: [equinox-dev] org.eclipse.equinox.util bundle

equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org wrote on 11/30/2007 08:08:22 AM:

> Hi all,

>

> For the org.eclipse.equinox.util bundle:

> https://bugs.eclipse.org/bugs/show_bug.cgi?id=206151

> I have some comments/questions.

>

> 1. Can I change the name to the "org.eclipse.equinox.internal.util"

> and kept here only the classes that are needed for more than one bundle?

There is no precedence for doing this in Eclipse. But it does make some

sense to me. This would make it obvious that the whole bundle is

really just an internal implementation detail. What do others think?

>

> 2. Still we will keep the bundle in the equinox distribution or we will

> move the classes to the org.eclipse.equinox.common.jar in the future?

For now I think we should make all the packages internal and use

x-friends where appropriate for the other service bundles. In the

future it is possible that we could move the packages to common and

make them real API with no "internal" name in the package. But we

will not do that unless the gain is substantial (i.e. needed by a

large set of clients in the Eclipse community).

>

> Next week I will work on removing dependencies and some packages from

> the util bundle but I need decision about the packaging and naming

> prior finishing the work.

>

> -Pavlin

Thanks Pavlin. For now you should move the packages out

of the equinox.util into other bundles where appropriate and rename

the remaining packages to include "internal" in the name with

x-friends for the bundles that need the package.

A final decision on the symbolic name of the util bundle can

be made after the package restructuring.

Tom.

_______________________________________________

equinox-dev mailing list

equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org

https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________

equinox-dev mailing list

equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org

https://dev.eclipse.org/mailman/listinfo/equinox-dev

headers

Andrew Overholt | 4 Dec 21:17

[prov] common bundlepool among multiple adminUIs

Hi,

I ran into what was supposedly a corrupt bundlepool again today so I 
re-provisioned an sdk from the test update site.  I verified that I was 
able to run this sdk without any problems.

I then unzipped the agent download in a different location, started the 
admin UI, added a profile in a different location than above but using 
the same bundlepool.  I then tried to provision the sdk into this new 
location.  Everything seemed to go alright except for the fact that it 
re-downloaded the launcher fragment and after it appeared to be finished 
I got the attached ZipException.  I've hit this a few times recently and 
always with cvs.source.

Is there something I'm doing wrong?

Andrew

location=file:/notnfs/overholt/p2/bundlepool/plugins/org.eclipse.cvs.source_1.0.100.v20070824-7C79Do9EI99hBQEZ.jar
java.util.zip.ZipException: error in opening zip file
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(ZipFile.java:131)
        at java.util.jar.JarFile.<init>(JarFile.java:150)
        at java.util.jar.JarFile.<init>(JarFile.java:87)
        at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:90)
        at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:66)
        at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:71)
        at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
        at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89)
        at java.net.JarURLConnection.getManifest(JarURLConnection.java:235)
        at org.eclipse.equinox.internal.frameworkadmin.utils.Utils.getOSGiManifest(Utils.java:241)
        at org.eclipse.equinox.internal.frameworkadmin.utils.Utils.getManifestMainAttributes(Utils.java:228)
        at org.eclipse.equinox.internal.frameworkadmin.utils.Utils.getClausesManifestMainAttributes(Utils.java:224)
        at org.eclipse.equinox.frameworkadmin.equinox.internal.EquinoxBundlesState.getSystemBundleFromBundleInfos(EquinoxBundlesState.java:142)
        at org.eclipse.equinox.frameworkadmin.equinox.internal.EquinoxBundlesState.getSystemBundleFromBundleInfos(EquinoxBundlesState.java:155)
        at org.eclipse.equinox.frameworkadmin.equinox.internal.EquinoxBundlesState.composeNewState(EquinoxBundlesState.java:307)
        at org.eclipse.equinox.frameworkadmin.equinox.internal.EquinoxBundlesState.<init>(EquinoxBundlesState.java:280)
        at org.eclipse.equinox.frameworkadmin.equinox.internal.EquinoxManipulatorImpl.getBundlesState(EquinoxManipulatorImpl.java:144)
        at org.eclipse.equinox.frameworkadmin.equinox.internal.EquinoxManipulatorImpl.save(EquinoxManipulatorImpl.java:372)
        at org.eclipse.equinox.internal.p2.touchpoint.eclipse.LazyManipulator.save(LazyManipulator.java:73)
        at org.eclipse.equinox.internal.p2.touchpoint.eclipse.EclipseTouchpoint.completePhase(EclipseTouchpoint.java:97)
        at org.eclipse.equinox.p2.engine.Phase.postPerform(Phase.java:177)
        at org.eclipse.equinox.p2.engine.Phase.perform(Phase.java:99)
        at org.eclipse.equinox.p2.engine.Phase.perform(Phase.java:58)
        at org.eclipse.equinox.p2.engine.PhaseSet.perform(PhaseSet.java:38)

headers

Pascal Rapicault | 4 Dec 21:59

Re: [prov] common bundlepool among multiple adminUIs

This is caused by a problem in the artifact repository manager that is not
properly restoring the repository representing the bundle pool as such.
I have opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=211922

PaScaL

                                                                                                                                               
  From:       Andrew Overholt <overholt@...>                                                                                            

  To:         equinox-dev@...                                                                                                          

  Date:       12/04/2007 03:24 PM                                                                                                              

  Subject:    [equinox-dev] [prov] common bundlepool among multiple adminUIs                                                                   

Hi,

I ran into what was supposedly a corrupt bundlepool again today so I
re-provisioned an sdk from the test update site.  I verified that I was
able to run this sdk without any problems.

I then unzipped the agent download in a different location, started the
admin UI, added a profile in a different location than above but using
the same bundlepool.  I then tried to provision the sdk into this new
location.  Everything seemed to go alright except for the fact that it
re-downloaded the launcher fragment and after it appeared to be finished
I got the attached ZipException.  I've hit this a few times recently and
always with cvs.source.

Is there something I'm doing wrong?

Andrew
location=file:/notnfs/overholt/p2/bundlepool/plugins/org.eclipse.cvs.source_1.0.100.v20070824-7C79Do9EI99hBQEZ.jar

java.util.zip.ZipException: error in opening zip file
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(ZipFile.java:131)
        at java.util.jar.JarFile.<init>(JarFile.java:150)
        at java.util.jar.JarFile.<init>(JarFile.java:87)
        at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:90)
        at
sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:66)
        at
sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:71)
        at
sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)

        at
sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89)

        at java.net.JarURLConnection.getManifest(JarURLConnection.java:235)
        at
org.eclipse.equinox.internal.frameworkadmin.utils.Utils.getOSGiManifest(Utils.java:241)

        at
org.eclipse.equinox.internal.frameworkadmin.utils.Utils.getManifestMainAttributes(Utils.java:228)

        at
org.eclipse.equinox.internal.frameworkadmin.utils.Utils.getClausesManifestMainAttributes(Utils.java:224)

        at
org.eclipse.equinox.frameworkadmin.equinox.internal.EquinoxBundlesState.getSystemBundleFromBundleInfos(EquinoxBundlesState.java:142)

        at
org.eclipse.equinox.frameworkadmin.equinox.internal.EquinoxBundlesState.getSystemBundleFromBundleInfos(EquinoxBundlesState.java:155)

        at
org.eclipse.equinox.frameworkadmin.equinox.internal.EquinoxBundlesState.composeNewState(EquinoxBundlesState.java:307)

        at
org.eclipse.equinox.frameworkadmin.equinox.internal.EquinoxBundlesState.<init>(EquinoxBundlesState.java:280)

        at
org.eclipse.equinox.frameworkadmin.equinox.internal.EquinoxManipulatorImpl.getBundlesState(EquinoxManipulatorImpl.java:144)

        at
org.eclipse.equinox.frameworkadmin.equinox.internal.EquinoxManipulatorImpl.save(EquinoxManipulatorImpl.java:372)

        at
org.eclipse.equinox.internal.p2.touchpoint.eclipse.LazyManipulator.save(LazyManipulator.java:73)

        at
org.eclipse.equinox.internal.p2.touchpoint.eclipse.EclipseTouchpoint.completePhase(EclipseTouchpoint.java:97)

        at org.eclipse.equinox.p2.engine.Phase.postPerform(Phase.java:177)
        at org.eclipse.equinox.p2.engine.Phase.perform(Phase.java:99)
        at org.eclipse.equinox.p2.engine.Phase.perform(Phase.java:58)
        at org.eclipse.equinox.p2.engine.PhaseSet.perform(PhaseSet.java:38)
_______________________________________________
equinox-dev mailing list
equinox-dev@...
https://dev.eclipse.org/mailman/listinfo/equinox-dev

9	February 2012
14	January 2012
19	December 2011
3	November 2011
27	October 2011
24	September 2011
49	August 2011
24	July 2011
49	June 2011
49	May 2011
59	April 2011
57	March 2011
46	February 2011
28	January 2011
47	December 2010
50	November 2010
30	October 2010
51	September 2010
21	August 2010
16	July 2010
70	June 2010
20	May 2010
80	April 2010
57	March 2010
37	February 2010
54	January 2010
62	December 2009
34	November 2009
50	October 2009
76	September 2009
71	August 2009
52	July 2009
107	June 2009
94	May 2009
121	April 2009
71	March 2009
77	February 2009
97	January 2009
35	December 2008
58	November 2008
116	October 2008
126	September 2008
57	August 2008
134	July 2008
193	June 2008
190	May 2008
207	April 2008
201	March 2008
215	February 2008
151	January 2008
96	December 2007
118	November 2007
203	October 2007
164	September 2007
173	August 2007
128	July 2007
156	June 2007
152	May 2007
93	April 2007
121	March 2007
180	February 2007
74	January 2007
48	December 2006
139	November 2006
110	October 2006
63	September 2006
37	August 2006
89	July 2006
143	June 2006
71	May 2006
51	April 2006
103	March 2006
114	February 2006
64	January 2006
42	December 2005
82	November 2005

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31