Bugzilla – Full Text Bug Listing
| Summary: | [fwkAdmin][shared] shared install eclipse.ini not read | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Pascal Rapicault <pascal> |
| Component: | p2 | Assignee: | Ian Bull <irbull> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | bsd, dj.houghton, heidwill, irbull, jason.madden, john.arthorne, lizeray, simon_kaegi, ts |
| Version: | 3.5 | ||
| Target Milestone: | 3.6 M5 | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 300303 | ||
|
Description
Pascal Rapicault
The root cause of the problem is that the configuration folder located in the shared install is not read. This is because the value specified in the config.ini for the parent configuration location is relativized against the install folder and the EquinoxFwConfigFileParser makes it use the osgi.install.area when it makes it absolute. DJ or Simon do you remember which bundles writes the config.ini in the user folder in case of a shared install? After further analysis the root cause of all this mess is the fact that the eclipse.ini from the shared install is not read which consequently cause plenty of path computation to go wrong. see also bug #258300 There's sufficien toverlap that we should track the testing and fixes in bug 258300 *** This bug has been marked as a duplicate of bug 258300 *** See related bug #258300 *** Bug 258935 has been marked as a duplicate of this bug. *** *** Bug 258834 has been marked as a duplicate of this bug. *** This is a regression since 3.4.0 (see comment #2 in bug # 258834). Adding a note to remind to re-enable the tests in SharedInstallTests for the Mac when this bug is done. Also see bug 258384 *** Bug 266603 has been marked as a duplicate of this bug. *** *** Bug 287241 has been marked as a duplicate of this bug. *** Is this a framework admin problem or a launcher problem? I'm going through this right now and the framework admin bundles don't even appear to be loaded? Does the launcher read the eclipse.ini file too? (In reply to comment #12) > Is this a framework admin problem or a launcher problem? I'm going through > this right now and the framework admin bundles don't even appear to be loaded? > > Does the launcher read the eclipse.ini file too? Never mind that last comment. I see what's going on. We fail to read the eclipse.ini file *before* we ever try to install something. After we install something the problem comes to light (p2 goes away). This is now fixed in 3.6 I have been working on a 3.5.x fix. I'm going to re-open this bug and assign it to myself so I can at least put the patch here. We can discuss if the patch makes sense for 3.5.2 or 3.5.2+. Essentially the problem breaks down as follows: The framework admin needs to determine the osgi install location. To do this, it checks a bunch of things 1. is OSGI_INSTALL_AREA set 2. if not, can we use the -startup parameter 3. if not, assume the osgi install location is at the same location as the launcher. Under all platforms we fail on #1 and #2, and therefor we assume 3. This is fine, except for Mac, where the launcher is actually in ./Eclipse.app/Contents/MacOS/ To determine we are on Mac we can either use the Environment Service, or check the directory name that the launcher lives in. (does it == MacOS). The fix is self contained as it only affects ParserUtils#getOSGiInstallArea and is similar to the fix that we have for 3.6 except we need a slightly different way to determine if we are running on a Mac. I realized it's probably better to clone this bug and discuss a 3.5.x fix there. Sorry about the spam. |