Community
Participate
Working Groups
Build ID: I20090129-1800 Steps To Reproduce: 1. Extract SDK to C:\35work\test9 2. Launch with the command .\eclipsec.exe -data C:\tmp\test9\workspace -configuration C:\tmp\test9\configuration -debug -console 3. Provision HelloWorld version 1.0.0 with p2 UI 4. Restart SDK and verify HelloWorld is installed and active 5.Start p2 UI and select install. 6. Select HelloWorld version 1.0.1 7. p2 UI informs that 1.0.0 is installed and this will be an update. 8. Finish install, restart and verify 1.0.1 is installed correctly 9. Shutdown SDK 10. Rename the install directory to C:\35work\test9_relo 11. Launch SDK using the same command (same workspace and configuration) .\eclipsec.exe -data C:\tmp\test9\workspace -configuration C:\tmp\test9\configuration -debug -console 12. Install HelloWorld version 1.0.6 with p2 UI and restart 13. Now there is no p2 UI, we have the old update manager which shows that version 1.0.6 is active More information: bundles.info has HelloWorld,1.0.1,../../../tmp/test9/plugins/HelloWorld_1.0.1.jar,4,false platform.xml has <?xml version="1.0" encoding="UTF-8"?> <config date="1234912181484" shared_ur="file:configuration/org.eclipse.update/platform.xml" transient="false" version="3.0"> <site enabled="true" policy="USER-EXCLUDE" updateable="true" url="file:../../../tmp/test9/"> <feature id="HelloWorldFeature" url="features/HelloWorldFeature_1.0.6/" version="1.0.6"> </feature> </site> </config>
Simon, please take a look when you have a moment. There may be something more underlying this.
I'll investigate this as part of shared install testing for m7. Jim, do you happen to have the repo you used still available.
I will find the repo for you.
Created attachment 132612 [details] test site This is an old site created in 2008. It seems compatible with the latest builds. Hopefully it is good enough for this test. I will run back through the test myself and verify that it still works as stated.
Using 0415-1348 The first thing that I see is that if I point to the old workspace and configuration using .\eclipsec.exe -data C:\35work\test9_relo\workspace -configuration C:\35work\test9_relo\configuration -debug -console I get a file C:\35work\test9\artifact.xml created. I would expect that it would work as it previously had since I am pointing to the same workspace and configuration. I would not expect it to create artifacts in the old directory.
It looks like the symptom of losing the p2 UI is gone. I will need to recreate the site with the current tools and add some additional flags in the test plugin to verify it is really correct. Also, it looks like the console is hosed. It is not available. I don't recall seeing that in my recent testing so this may be related to the change in launch parameters. I will check that out after working on the test site.
It looks like the basic test works now. However there were other items that are wrong. - The creation of artifacts.xml in the old directory is wrong. - The console is not working for me. - I was expecting trouble building the site because of the md5 checksum in artifacts.jar but the new build using the publisher does not seem to have this. Please let me know if you want new bugs for any of these. I will append the new update site for HelloWorld.
Created attachment 132629 [details] test site Test site.
The console not working is an IBM JVM 1.6 problem. It works with SUN JVM. I will open a new bug for that.
Thanks for the repo - made testing this out much simpler. When I first read this bug my first thought was WONTFIX. I think all in all that's where I still stand (and am marking it that way) as I don't think we can provide universal support and I'm not sure how far down this rabbit hole we should go. With that said (and as you've found) we're actually remarkably resilient to moving the shared install folder so I'll try and detail a bit on what seems to work reasonably well and what doesn't. - 1) If the user install has not installed any new bundles via dropins or the UI everything looks fine. 2) If the user install has installed new bundles however the moving of the install folder keeps the same relative paths intact we come back up and everything appears to works correctly. I didn't perform a really exhaustive analysis but from what I saw the bundles.info, config.ini, and profiles all looked correct. To be on the safe side I'd recommend running the shared install once to reset some of the profile roaming locations and update the timestamp as this will let the "user" install recognize something signficant has changed. 3) If the install folder is moved such that it changes the correctness of any of the relative paths in the user install we still come up however the installs state is no longer accurately calculated and most provisioning operations end up writing bogus values out. In particular what I noticed were that the bundles.info contained incorrect paths as well as a number of similar path problems in config.ini. platform.xml looked correct to me however it's easy to imagine problems in this file too. In this state we're not really recoverable without some external tool to sort things out and correct the various values using provisioning operations. For now I think the best advice we could give at this point is to delete the configuration and p2 folders and re-start allowing the install re-initalize from the new install location.
A relocatable install space is not an option for us. The fact that the artifact.xml is getting written to the wrong area can not be right unless I have made a mistake in how I executed the test and that is possible. The case we need to support is an admin install somewhere and then shared (as in mounted). So the renaming was to simulate that. And rerunning to allow fix ups won't always work. The change in install path happens because of the mount. This does not have to be fixed for 3.5 since we are not basing our products on this yet. However we will need to fix in the next release. I will be able to help with that at some point. In the end, the only problem identified in this bug was the creation of the artifact.xml in the wrong location. The severe problems originally found seem to be fixed.
(In reply to comment #11) > This does not have to be fixed for 3.5 since we are not basing our products on > this yet. However we will need to fix in the next release. I will be able to > help with that at some point. Thanks Jim, that would be good to get help on this. The problem here is that we need to clean up the existing configuration state and then trigger the (p2 level) re-installation of all the bundles from the shared install. I have some ideas on how we might accomplish this however nothing concrete so I'd be hesitant to do anything for 3.5. > In the end, the only problem identified in this bug was the creation of the > artifact.xml in the wrong location. The severe problems originally found seem > to be fixed. We indeed come back up because we'll detect an inconsistency between the user and shared install and run off of the shared install's state. If you take a close look at your configuration you'll find problems worse than the mis-placed artifact.xml. For example, your bundle.info will still contain paths pointing at the original install location. Likewise, the state calculation done in FrameworkAdmin will not find the simple configurator bundle and as a result will put any new bundles installed on the osgi.bundles list.
I agree there are other problems. For instance bug 265210. I was trying to limit the scope of this testcase to just relocation of install directory.
I'm not planning on doing anything for 3.6 on this.
This may or not work. No plan to work on this.
