Bugzilla – Full Text Bug Listing
| Summary: | [shared] osgi.framework is written in both shared and user config.ini | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | DJ Houghton <dj.houghton> | ||||||
| Component: | p2 | Assignee: | DJ Houghton <dj.houghton> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | conanc, irbull, john.arthorne, makandre, pascal, pwebster, tjwatson | ||||||
| Version: | 3.7 | ||||||||
| Target Milestone: | 3.7 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
DJ Houghton
Created attachment 182777 [details]
initial patch
Initial patch which recognizes the osgi.framework property, makes both the shared and user locations absolutes URIs, and then does the comparison.
Normally, fwkadmin should *always* deal in absolute URIs. That is, when it reads from disk, relative URIs should be made absolute, and any URI set by through the API should be absolute. The fact that you have to make it absolute on save is kind of weird to me. Did you check how we end up with a relative URI at this stage? (In reply to comment #0) > 2). It can be argued that the osgi.framework property should never be written > to the user's local copy of the config.ini. If it is and if the shared install > is updated to use a new copy of the framework, then the new install will not > work. If I understand correctly, if we *ever* write the osgi.framework property in the user's private config.ini, then we will never be able to upgrade the framework again for that install (because we have special code that detects this case in ConfigApplier and bails out). If this understand is correct, I think we should just never write the osg.framework property in the user's local config.ini in a shared install. *** Bug 326682 has been marked as a duplicate of this bug. *** Created attachment 183000 [details]
patch
Patch which removes the osgi.framework property from the user's local config.ini.
Tom: what are your thoughts about changing the code in the launcher so we never read the osgi.framework property from the user's config.ini file? The current patch never writes it so adding code to never read it might help us with migration problems for users who currently have a value written locally but the shared content has been updated. (In reply to comment #2) > Normally, fwkadmin should *always* deal in absolute URIs. That is, when it > reads from disk, relative URIs should be made absolute, and any URI set by > through the API should be absolute. > > The fact that you have to make it absolute on save is kind of weird to me. Did > you check how we end up with a relative URI at this stage? I have confirmed that it is the product's installer which writes out the osgi.framework property as an absolute URL and verified that the p2 code does the right thing and tries to make things relative. (In reply to comment #6) > Tom: what are your thoughts about changing the code in the launcher so we never > read the osgi.framework property from the user's config.ini file? The current > patch never writes it so adding code to never read it might help us with > migration problems for users who currently have a value written locally but the > shared content has been updated. I missed this question, sorry. If you never want the osgi.framework property to be read from the users config.ini then you could set the property (as a VM -D arg) in the eclipse.ini instead of the config.ini. -D VM property settings take priority over any options set in the config.ini files. *** Bug 336176 has been marked as a duplicate of this bug. *** Patch released. We no longer write out the osgi.framework property in the user's config.ini file in the shared install case. (comment 3) The product originally reporting this bug has been able to work around their problem by using the mechanism specified in bug 330133. Closing. |