Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #258365 +++ I20081210-0800 When I install something in shared install I loose my p2 menus.
My comments from Bug 258365: 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.
Ian, when you have a patch, please try cross platform product export from the mac. We won't want it changing the path if we are installing for a different platform.
Created attachment 157211 [details] org.eclipse.equinox.frameworkadmin.equinox.patch This patch changes the OSGi install area lookup on a Mac.
(In reply to comment #2) > Ian, when you have a patch, please try cross platform product export from the > mac. We won't want it changing the path if we are installing for a different > platform. Great call Andrew! I have decided to use both checks, 1) that your launcher is in a directory called MacOS and 2) you are on a Mac. This way cross platform export won't use this code path. I have tested this out, and it appears that export doesn't even use this method to compute the OSGi install location. As an aside: on Mac, I cannot get the launcher to appear under the root folder (with the proper sym link). I have the delta pack in my target and I'm doing cross platform exports (while generating metadata). This problem has nothing to do with this patch, as the problem persists on a fresh 3.5.1 install. Maybe I just missed a step (missing a fragment or something), or I have the wrong platform filters set. I'll find a knowledgeable Mac users tomorrow and pick their brain. If somebody would like to review this patch, it would be greatly appreciated. I could not use the normal path computations (on IPath) as there is no dependency from frameworkadmin to core.runtime. Instead, I just traverse up 3 directories using getParentFolder with null checks in between.
As mentioned on the p2 call, the director call to install the product during export takes place in a separate process so you won't hit break points in that operation. The director call is made in org.eclipse.pde.build/scripts/genericTargets.xml runDirector. There is an ant property there "p2.director.extraVMArgs", the default value is "-Declipse.p2.MD5Check=false". I haven't tried, but I think you should be able to set this property in your workspace preferences -> ant -> runtime -> Properties to also include -X args to enable debugging on the separate process.
With the final planned 3.5.2 build in two days I think we've run out of time. We can put it in the 3.5.x branch after the 3.5.2 release, and of course fix in 3.6 stream.
Ian could you please see if this still an issue in 3.7?
As far as I can tell this is working.
