Summary: | Automatically started plugins should not be uninstalled | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Dorian Birsan <birsan> |
Component: | Update (deprecated - use Eclipse>Equinox>p2) | Assignee: | Dorian Birsan <birsan> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | blocker | ||
Priority: | P1 | CC: | ed.burnette |
Version: | 3.0 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Dorian Birsan
2004-04-28 22:05:59 EDT
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. |