Community
Participate
Working Groups
Build Identifier: I20100608-0911 Our product upgrade process works by first removing the old Eclipse product and then installing a new one in the same location. This means that the -uninstallIU and -installIU happen in separate director calls. I've found that this leads to a broken installation if there are other plugins installed at the time. If I use a single call that does -uninstallIU our.product -installIU our.product, then the resulting config.ini is correct: osgi.framework=file\:plugins/org.eclipse.osgi_3.6.0.v20100517.jar osgi.bundles=reference\:file\:org.eclipse.equinox.simpleconfigurator_1.0.200.v20100503.jar@1\:start If I do the -uninstallIU and then the -installIU then the result is: osgi.framework=file\:plugins/org.eclipse.osgi_3.5.2.R35x_v20100126.jar osgi.bundles=reference\:file\:org.eclipse.osgi_3.6.0.v20100517.jar@4,reference\:file\:org.eclipse.equinox.simpleconfigurator_1.0.200.v20100503.jar@1\:start The 3.5.2 org.eclipse.osgi bundle no longer exists on disk after the garbage collector runs but osgi.framework is not updated. I've debugged this. Here's why the two cases are different. In both cases, the framework jar is recomputed after the p2 operation by EquinoxManipulatorImpl#getBundlesState, eventually arriving at EquinoxBundlesState#getSystemBundleFromBundlesInfo. If the uninstall and install happen at the same time, then the old bundles are removed as part of the profile update, so the list of bundles searched only includes the new org.eclipse.osgi. But if the product uninstall had already happened, then the now-unnecessary org.eclipse.osgi bundle is not removed by the current p2 operation. It's still in the front of the bundle list and is selected as the framework jar. Later on, the garbage collector runs; the 3.5.2 OSGI jar is deleted; the platform fails to start. Recomputing during garbage collection if the framework jar is deleted would work, but is not right; the new OSGI jar is not part of the upgraded profile and should not be used. Possibly related: configuration/org.eclipse.equinox.simpleconfigurator/bundles.info still references the bundles that have been garbage collected. So far, my idea is to select the largest version of the framework jar which is found. This would break in downgrades, if that is a supported mode, or if an old profile is present. But it works in the simple case. Reproducible: Always Steps to Reproduce: You can reproduce this with the EPP packages. You'll need mirrors of the relevant bits of Galileo and Helios (epp.package.cpp and org.eclipse.emf.sdk.feature.group). director="java -jar /usr/local/tools/gcc-4.3.3/eclipse-3.6/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar -application org.eclipse.equinox.p2.director -data $PWD/workspace -destination $PWD/eclipse -profile SDKProfile -p2.os linux -p2.ws gtk -p2.arch x86 -roaming" $director -repository file://$PWD/galileo -installIU epp.package.cpp $director -repository file://$PWD/galileo -installIU org.eclipse.emf.sdk.feature.group $director -repository file://$PWD/galileo -uninstallIU epp.package.cpp $director -repository file://$PWD/helios -installIU epp.package.cpp At the end of this config.ini will be broken. If the last two are combined, it won't be broken.
Created attachment 179195 [details] Proposed patch This patch implements my idea from the previous comment, and works for our product.
We have a patch, so I'll put this on Kepler so we can look at this.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
