Community
Participate
Working Groups
Here is the scenario that made me unhappy: 1) Install clean 3.0.0 2) Activate automatic updates (could be manual as well) and update to 3.0.1 3) After restart, verify that you are running 3.0.1 4) Open 'Manage configuration...' window and revert to 3.0.0 5) After the revert, try to uninstall 3.0.1 Problem 1: Uninstall fails silently because it cannot delete osgi and runtime plug-in jars. Problem 2: Upon restart, Eclipse fails to run because certain files were deleted. The core of the problem is that the revert step (in which we unconfigured 3.0.1 and configured 3.0.0 plug-ins) failed to communicate this information to OSGi. Upon restart, OSGi will pick the latest version on the disk, not the one we want it to pick. We will have a mixed system now (mostly 3.0.0 except OSGi and runtime). Naturally, an attempt to remove these plug-ins will fail since JARs will be in use. My expectation as a user are that Eclipse obays my commands (my authoritah!). There may be valid reasons why I want an earlier version of OSGi to run (for example, a patch delivered for OSGi or runtime plug-in may cause problems on my machine, so I want to revert to a previous, stable version). Update and OSGi should talk to each other and communicate this information so that the cache is flushed/updated and startup picks the desired version. Picking the latest version on disk is a problematic strategy in the context of Eclipse.
*** Bug 74386 has been marked as a duplicate of this bug. ***
By way of explanation... Startup.jar searches for the osgi bundle if none is identified by the configuration. If it finds multiple, it chooses the one with the highest vesion number as seen by the directory name. OSGi then uses a similar technique to find the bundles listed on the osgi.bundles list. The first problem "could" be addressed by setting the appropriate system property (osgi.frameworkPath or some such). This of course is brittle in its own way but would in fact allow you to be very specific. The second problem cna be similarly solved by identifying on the osgi.bundles line the exact version of the bunde you want. Note that I believe you do not have to spec the full path. You can just do something like osgi.bundles = org.eclipse.core.runtime_3.0.0 In fact, you might be able to do sometihng similar for to identify the OSGi bundle to use. (if you can't and think it is a good idea, open a bug on runtime)
*** Bug 91334 has been marked as a duplicate of this bug. ***
*** Bug 97759 has been marked as a duplicate of this bug. ***
Dorian, Jeff, this is not a trivial problem and should be addressed. If we don't, it means that we can not go backwards with OSGi version - once you move to the next, you cannot revert.
increased priority, but not sure if one can get a stable fix in the remaining 3.1 dev time.
Given that there are two possible workarounds listed in comment 2, and that this code is deep in the bowels, I suggest defering any changes at the runtime level. Update could theoretically be enhanced to update the config.ini or eclipse.ini to implement the workarounds or that could be left to product installers. Again, at this point in 3.1 it does not seem like we have time to do a reliable fix.
We should at least document this in the readme for those 3 people that actually read it.
added entry to readme for 3.1
Will not be done in 3.3
The Eclipse Update component is no longer under development, and no longer exists in the Eclipse Platform 4.x stream. If this problem still occurs in Eclipse Platform 4.2 or later, please enter a new bug report against Equinox p2.
