Community
Participate
Working Groups
Update should refrain from storing absolute paths in the configuration area. The intention is to support the scenario requested by bug 88234: running from a read-only, movable, pre-initialized location. The framework is being changed to support that. We are (politely) asking other plug-ins that write to the configuration area to do the same.
Currently, the only absolute paths are those of linked installation locations or installations locations added by the user (via Add Extension Location). The default eclipse install is used as platform:/base/, in which case things should work fine, provided a platform.xml file is provided.
Cool, so this is a non-issue.
Rafael, note that the update configurator may still want to write to the configuration area, I have not tested that it actually works with a read only config. The assumption so far was the the runtime will always provide a read/write configuration location. My previous comment was true with respect to the full paths used by the update configurator, but this may not be sufficient to address all your requirements. Please reopen the bug if needed.
Original summary: "avoid storing absolute paths in the configuration area" You are right. There are two sides to the issue. Changing summary to reflect that. Location has a isReadOnly() API. If that is true, the Update plug-ins should work in some sort of read-only mode. However, I don't know what interesting features could still be provided by Update in that mode.
Created attachment 19527 [details] patch for update.configurator Re: comment 1 - actually there is an issue. Update configurator will use absolute URLs to install new bundles/discover bundles to remove. This patch changes the configurator so it tries to relativize URLs.
Dorian, could you review the patch when you have some time? We only want your feedback to validate the approach for now, we do not expect you to release the code yet. Thanks.
Thanks Rafael. The patch looks ok, but I cannot start eclipse in feature based self hosting mode. I get this kind of error messages: !ENTRY org.eclipse.update.configurator 2005-04-04 20:47:09.300 !MESSAGE Could not install bundle plugins/org.apache.ant/ null !ENTRY org.eclipse.update.configurator 2005-04-04 20:47:09.300 !MESSAGE Could not install bundle plugins/org.apache.lucene/ null It looks like you need to change the line that installs a bundle: Bundle target = context.installBundle(UPDATE_PREFIX+bundlesToInstall[i], bundleURL.openStream()); as well as to ensure that the code that finds the bundles to install/uninstall works fine with relative path locations (it probably does, and relative paths should make the lookup faster). Note that the automatically configured bundles should also be installed with a relative locations (currently they aren't).
Dorian, when you tried running, did you apply the patch for org.eclipse.osgi I added to bug 72851 (attachment 19526 [details])? I didn't mention it, but should have.
no, I was running with the m6 build. With the osgi patch only (I did not apply the other patch to eclipse starter) everything worked fine.
Not sure I got you right, Dorian... the patch to org.eclipse.osgi (attachment 19526 [details]) has changes to ReferenceURLConnection, EclipseAdaptor, EclipseStarter, and FilePath classes. That is the only patch that should be applied (in addition to the configurator patch added here). Is that what you did? If so, and everything works now, from comment 7, what statements would still be valid?
I only applied the patch to ReferenceURLConnection, as it was the only one that showed "org.eclipse.osgi" and thought the other ones were for runtime. It turns out that everything worked with only *that* portion of the patch. Using the full patch I get: !ENTRY org.eclipse.osgi 2005-04-05 11:22:13.854 !MESSAGE Bundle org.eclipse.core.runtime@2:start not found. !ENTRY org.eclipse.osgi 2005-04-05 11:22:13.854 !MESSAGE Bundle org.eclipse.update.configurator@3:start not found. and this is before and after I remove everything but config.ini from the configuration. BTW, another issue we may need to consider is dealing with existing configurations (caches, etc.) and also supporting the update of eclipse to 3.1
Created attachment 19651 [details] patch for org.eclipse.update.configurator Minor improvements over previous patch. See bug 72851 for new patch against org.eclipse.osgi.
I can't apply the patch to osgi from HEAD, there are some mis-matches.
Dorian, that patch has been released already, so you just have to have OSGi from HEAD. Sorry for not making it clear. Can you try the feature based workspace layout scenario and see if there are any problems? I have tried many scenarios, but not that one.
Things worked fine for me as well.Should I be releasing the patch?
Please do so, Dorian. One thing that still needs to be done is to do the same relativization of URLs (having the install URL as base) for the external site locations stored in platform.xml. The scenario we want to support is one where if an initialized Eclipse install with external locations is moved/copied to a different location (with timestamps preserved), no changes should be noticed by update. As far as I can see, the only missing piece is the use of install-relative site locations.
The install relative location for sites is needed. The configurator is already trying to store them relative to platform:/base/ (see org.eclipse.update.internal.configurator.Utils.asPlatformURL() ) but that is never used, as platform:/base/ points to the eclipse installation, and all the external sites are outside the eclipse folder. For example, the RAD/WSAD tools have install_dir eclipse linked_site1 linked_site2 BTW, code is checked in.
In that scenario, we would have site URLs in the following form: ../linked_site1/ ../linked_site2/ The code in ConfigurationActivator#makeRelative() could be used for that - the reference being the resolved install URL (e.g. as returned by Platform#getInstallLocation().getURL()). To go the other way, creating a Path object with url.getPath() should take care of it. Of course, if a linked site where located in a different volume, then they would not be made relative. But that is fine. To avoid widespread changes, one idea would be to make them relative just before saving and converting them back to absolute right after reading. Do you see issues with doing that? Thanks for releasing the patch.
That sounds good. I won't have time to look at this week, hopefully sometimes next week (unless you have some cycles to investigate this)
Great. I might give it a try today or early next week. I will add a patch here when I have something to show.
*** Bug 94746 has been marked as a duplicate of this bug. ***
I will be looking into this. Bug 94746 is a related issue (config.ini generated by PlatformConfiguration#linkInitializedState is absolute).
Created attachment 21147 [details] patch for org.eclipse.update.configurator This patch implements what is discussed from comment 16 on. I decided back off changes to address the sharedConfiguration property (bug 94746) because org.eclipse.osgi does not know how to handle that yet. Will reopen bug 94746 so it gets addressed later.
Rafael, how does the patch address the comment #18 ? BTW, the patch does not work against the code in HEAD, apparently I can't apply the patch as is.
Created attachment 21211 [details] patch for org.eclipse.update.configurator This implements what is described in comment 18. We translate URLs after reading (i.e., after parsing) and before saving (i.e. while building a XML DOM). So they are always persisted as install relative URLs. URLs in different drives are not made relative. Weird, after sync'ng again today, I still don't get any incoming changes. Anyway, I am replacing the patch. Please try again.
The previous path (the one you tried before) was definitely invalid. It was probably the same patch I had provided on April 7th (see the file sizes). The new one should be ok.
The patch looks fine. I didn't look at the details of the makeRelative() functions, but I assume you handle different drive letters as well (likely the IPath does it).
The different case for drive letters, you mean?
no, I meant using relative paths when install location is on a different drive: c:\eclipse and another local install is on d:\other\site
Yes, we handle that case in the first lines of Utils.makeRelative(IPath,IPath).
The patch to bug 94746 includes these changes, so if that PR is fixed, this one won't require any further work.
This has been fixed in the context of fixing bug 94746. Closing. Many thanks to the Update team for reviewing and releasing the proposed changes.
