Community
Participate
Working Groups
Build Identifier: M20100211-1343 With Eclispe 3.5.2: If you drop another version of the org.eclipse.equinox.concurrent plugin into the plugin directory, p2 detects this and adds it to the bundles.info file. But it also removes the actual entry of this plugin from bundles.info. Every other version of this plugin(if you drop them in plugins) is referred in bundles.info, except the one that comes with Eclipse 3.5.2(the version referred in artifacts.xml) Note: If I remove or edit the version entry of org.eclipse.equinox.concurrent in the artifacts.xml file, the plugin can be found in the bundles.info file again. Actually this behavior leads to problems in our product(or in general to problems with extension locations in Eclipse), as we also experienced the following: (Maybe this should be another bug?) Extension locations are no longer detected if you use a custom configuration area, different from the standard configuration area. To reproduce this we did the following: 1. Reset the configuration and p2 directories to a clean/never used state. 2. Drop a product(e.g.: jdt) in the dropins folder. 3. Start eclipse with a user defined configuration location: eclipse -configuration /${customLocation} 4. See that stuff in extension locations are not detected. After some quick debugging we assumed, that Eclipse detects a disconnect between the shared configuration location bundles.info and the user defined configuration location bundles.info, and therefore falls back to the shared configuration location bundles.info where no extension locations are referred yet. Reproducible: Always Steps to Reproduce: 1. Install Eclipse 3.5.2 2. Copy another version of the org.eclipse.equinox.concurrent plugin into plugins(e.g.: org.eclipse.equinox.concurrent_1.0.0.v20090807-1800.jar, but was also reproducible with other versions) 3. Start Eclipse 4. Check bundles.info, org.eclipse.equinox.concurrent_1.0.1.R35x_v20100209.jar has been removed, the other Version/s has/have been added.
I see several bugs caused by p2 doesn't install the bundles of user configuration in runtime, such as Bug 317757, Bug 317896. What's the intent of current mechanism where picking up the bundles, share configuration or user configuration? I think it should load the bundles.info from user configuration if it exists, which is created and maintained by p2 as well.
Pascal, do you know what might be going on here? I did some initial testing in a non-shared environment and it uninstalled the old version and installed the new one from the dropins. The org.eclipse.equinox.concurrent bundle is non-singleton so I would assume that adding a new version to the dropins folder would install both bundles. The plan coming back from the Planner said that it was a bundle update rather than an addition.
(In reply to comment #2) > Pascal, do you know what might be going on here? > > I did some initial testing in a non-shared environment and it uninstalled the > old version and installed the new one from the dropins. The > org.eclipse.equinox.concurrent bundle is non-singleton so I would assume that > adding a new version to the dropins folder would install both bundles. The plan > coming back from the Planner said that it was a bundle update rather than an > addition. DJ, from what I remember debugging this the setup was this: - nobody really "requires" org.eclipse.equinox.concurrent -- No hard dependency on it from either a feature or a plug-in makes it pretty unique in the SDK - one optional dependency is probably the reason for including it in the SDK - the optimizer back then favored the newer, remote version over the old version from the profile So, even if the bundle is not a singleton there would be no need to keep around two versions of it, which is probably why the satisfier decides to update. my 2c Helmut P.S.: With 3.6 we'll favor the local, lower version (can we test this?), but the underlying bug of removing the old version from the shared configuration and deciding that the two config areas were then out-of-sync will still be there in cases where an explicit update is attempted...
CQ:WIND00211087 Ping, any update on this?
The explanation provided by Helmut is correct. This is the expected behaviour since nothing strictly depends on the previous version of the bundle. Note though that in 3.6 some tweaks got done to the resolution algorithm but it should not impact this behaviour.
