Community
Participate
Working Groups
Jeff, Pascal and I have discussed this quite a bit, but never opened a bug for it. So here it is: update should not attempt to uninstall the automatically started bundles (osgi, runtime, configurator) because it did not install them itself. These bundles appear on the osig.bundles property. More generally, update should not uninstall any bundles that it did not install (this could include bundles that have been installed by other configurators). An example of this problem can be seen when updating eclipse itself (Ed's posting on the mailing list): !SESSION Apr 28, 2004 16:50:01.722 -------------------------------------------- - java.version=1.4.2_04 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US !ENTRY reference:file:c:/Program Files/eclipse/plugins/org.eclipse.core.runtime_3.0.0/ 0 0 Apr 28, 2004 16:50:01.738 !MESSAGE FrameworkEvent.ERROR !STACK 0 org.osgi.framework.BundleException: The bundle could not be resolved. Reason: probably another version has been chosen at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker (BundleHost.java:395) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume (AbstractBundle.java:371) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle (Framework.java:1007) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles (StartLevelManager.java:571) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL (StartLevelManager.java:482) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel (StartLevelManager.java:272) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent (StartLevelManager.java:442) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent (EventManager.java:153) at org.eclipse.osgi.framework.eventmgr.EventThread$Queued.dispatchEvent (EventThread.java:56) at org.eclipse.osgi.framework.eventmgr.EventThread.run(EventThread.java:107) !ENTRY reference:file:c:/Program Files/eclipse/plugins/org.eclipse.core.runtime_3.0.0.v20040426a/ 0 0 Apr 28, 2004 16:50:01.801 !MESSAGE FrameworkEvent.ERROR !STACK 0 org.osgi.framework.BundleException: Exception in org.eclipse.core.internal.runtime.PlatformActivator.start() of bundle org.eclipse.core.runtime. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator (BundleContextImpl.java:990) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start (BundleContextImpl.java:952) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker (BundleHost.java:408) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume (AbstractBundle.java:371) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle (Framework.java:1007) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles (StartLevelManager.java:571) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL (StartLevelManager.java:482) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel (StartLevelManager.java:272) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent (StartLevelManager.java:442) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent (EventManager.java:153) at org.eclipse.osgi.framework.eventmgr.EventThread$Queued.dispatchEvent (EventThread.java:56) at org.eclipse.osgi.framework.eventmgr.EventThread.run(EventThread.java:107) Nested exception: java.lang.NoClassDefFoundError: org/eclipse/osgi/service/systembundle/EntryLocator at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at org.eclipse.osgi.framework.internal.defaultadaptor.DefaultClassLoader.defineCla ss(DefaultClassLoader.java:296) ...
If Update doesn't uninstall them then how can Eclipse update itself?
Those bundles are listed in config.ini and the framework is started by reading the osgi.bundles properties and locating the appropriate bundles. Currently, version is not shown in config.ini, so the latest version found wins. During updates, the update manager is supposed to update config.ini as necessary, or, as in this case, leave it untouched. The framework should uninstall the old version of those bundles and install the newer version. There is another bug for updating the config.ini, but for the time being, that one is not needed.
Fixed. After discussions with Jeff and Tom about osgi install API's, we decided to use a little trick to identify the configurator that installs the bundles. As such, we first wrap the old install url (reference:file:/d:/eclipse/plugins/some_bundle/) by an update url (update:reference:file:/d:/eclipse/plugins/some_bundle/) and call context.install(url.toExternalForm(), url.openStream()) so that the location is the url external form and the update can later query it and see if the bundle was one installed by it. Note: because the org.eclipse.osgi bundle does not keep track of location but it returns "SystemBundle", the update configurator is still trying to install it but fails. However, it will not uninstall it (that's the bug report). I will try to see if this fixes the updating of eclipse itself, or there is more needed.
