Community
Participate
Working Groups
Build ID: 3.4 M6 Our provisioning software installs a bundle as an osgi.bundle in the config.ini with a start level. In addition we run with our cache located in a different directory than the profile install directory. We ran into multiple problems trying to update this bundle to a newer version. There were many layers to the overarching problem and as we peeled off one layer another problem would appear. These problems were: 1. ArrayIndexOutOfBounds while sorting operations. This is bug 216050. 2. The EquinoxFwConfigFileParser tries to get the bundles for entries in the osgi.bundle property of the config.ini file. The current code path assumes the latest version of the bundle is the correct version. This is often wrong when you have a common cache directory and many versions of the same software cached. 3. The ConfigurationWriter assumes that it can write relative paths to the platform.xml file. We found this breaks 3.3 support. 4. The PlatformConfigurationWrapper assumes that it can read the configuration files from the OSGi install location. Our understanding of the OSGi install location is that it is synonymous with the cache directory. 5. The EclipseTouchpoint throws away configuration data by writing the data stored in the manipulator before writing the data stored in the PlatformConfigurationWrapper. 6. Finally, the SimplePlanner is using a private property to search for and mark IUs as root IUs. This means that only IUs that are updated are considered root IUs later on. Note: If you just use the planner and the engine, you have to add the root IU property yourself.
Created attachment 94947 [details] p2-update-and-reliability.patch.txt Notes for helping understand this patch: We're quite confused about what the proper value of the OSGi install area should be. In some code it is set to be the cache directory and in other code it is set to be the directory of the launcher, that is, the install directory of the profile. #P org.eclipse.equinox.p2.touchpoint.eclipse Index: src/org/eclipse/equinox/internal/p2/touchpoint/eclipse/EclipseTouchpoint.java Reordered the PlatformConfigurationWrapper & Manipulator save calls to allow the features that were added to the wrapper (and still in memory) to be written to disk before the manipulator re-read them off of disk and updated the file. This is 3.3 support. Index: src/org/eclipse/equinox/internal/p2/touchpoint/eclipse/LazyManipulator.java Added a getter to the profile so that we could later use the profile to get the install directory. Index: src/org/eclipse/equinox/internal/p2/touchpoint/eclipse/PlatformConfigurationWrapper.java Uses the new getter (see above) to determine the profile directory. Note that here the code was returning the launcher/install directory as the OSGi directory. This was necessary because in some configurations the bundles are not installed under the install directory. Is this the wrong usage of the term "OSGi Install Area"? Index: src/org/eclipse/equinox/internal/p2/update/ConfigurationWriter.java We understand that this code will break roaming profiles, however we couldn't come up with a way to make this code work when the bundles are not co-located with the configuration. Keeping the references absolute allows the non-co-located case to work. This also aided the 3.3 support as we had issues using relative paths in the platform.xml under Eclipse 3.3. Index: src/org/eclipse/equinox/internal/frameworkadmin/equinox/EquinoxFwConfigFileParser.java As the FIXME comment notes this is a hack and we're hoping to use this to open a discussion about what the right solution is. The problem it is solving is that the file parser is trying to get bundle infos for the bundles that are specified in the osgi.bundles property in the config.ini file. If the bundles listed did not include locations or version numbers the code would select the latest version, which wouldn't even necessarily be in the platform.xml or bundles.info file. This was a big deal for 3.3 because it would pick up 3.4 versions of bundles. Suggestions welcome! Index: src/org/eclipse/equinox/internal/frameworkadmin/equinox/EclipseLauncherParser.java We were encountering problems during the uninstall phase where the older version of a bundle was not in the plan, but continued to be written to the platform.xml file. We tracked the issue down to the fact that the launcher data object did not contain the right bundles. This was in turn caused by the incorrect configuration directory. Here we believe the configuration directory can not use the osgiInstallArea (which we believe to be the cache directory in this particular usage). Instead it must use the launcher folder. This may have not been noticed in 3.4 because the SimpleConfiguratorManipulatorConfigurator's clear method is called and all bundles are forgotten. Index: src/org/eclipse/equinox/internal/p2/director/SimplePlanner.java Rewrote the sortOperations() method to fix Bug 216050. This avoids the potential issues of index out of bounds. The updatePlannerInfo method was using a private variable to find & mark the root IUs. Switched to using the public one that is used by the director. Also left in code to provide migration to this new technique. We're not sure we should be marking all bundles that are updated as root IUs. However, the director does this marking so we thought it necessary.
I realize that some of the code in the patch is not up to the Eclipse platform's standard. Rather than dismiss it outright, please let's start a discussion about it. I have time to contribute to the project and these fixes are important to the reliability and stability of p2. If they don't work just right, let's iterate a few times and make them work.
I have glanced through the changes and they are scary :-) Most the changes touches in a very sensitive / brittle area of the code and we need to be extremely cautious to fix these especially that for this release 3.3 compatibility is not a priority for our main use cases (even though something we would like to have). So before engaging into further investigation I would appreciate if you could write a few test cases showing the problems in the fwk admin area (see project org.eclipse.equinox.frameworkadmin.test for examples of test in the fwk admin space). This will also help us fix the issues more easily since we won't have to run through complex setups. More specific feedback: - The patch on EclipseTouchpoint does not apply on HEAD anymore. - The computation of the osgi.install.area is not a trivial thing. It happens that most the time it is in the bundle pool, but the reality is a bit more complex and longer than I really want to describe here. However be sure that it took us a fair amount of time to get this straighten out for our 3.4 cases. In short the change in EclipseLauncherParser is a not good. - >Uses the new getter (see above) to determine the profile directory. Note that here the code was returning the launcher/install directory as the OSGi directory. Could you please determine the exact case where this is broken? - A code comment refers to updateconfigurator.manipulator, is this available some place? - For maintainability, I think that it would be good if we could organize the code such that there is no confusion (and unfortunate breakage) between 3.3 and 3.4.
I don't see anything happening on that front for 3.4. Closing as wontfix. Please reopen if you think otherwise.
