Community
Participate
Working Groups
build 20070921-1856 - download and extract agent zip - download and extract servers.zip - run agent - add local repositories - create new profile in d:\temp\zz_p1 with the bundle pool location at d:\temp\zz_p1\cfg\bundlepool - install the agent into the new profile - try and start up the agent in d:\temp\zz_p1 There seems to be problems with the SimpleConfigurator... it can't install the bundles. What exactly are the file: URLs in the bundles.txt supposed to be relative to? Tom says that relative reference:file: URLs are relative to the osgi.install.area.
CC'ing Tom because DJ's experiments do not match with Tom's statement.
I have no idea where to find the p2 builds. By some pretty miraculous searching I did find the 20070921-1656 builds (but only on an internal build machine, not the public eclipse download site). Please point me to where the 20070921-1856 build downloads are. Actually now that I think about it 20070921-1856 is probably a typo, right? It should be 20070921-1656 I guess.
org.eclipse.equinox.launcher.Main is setting osgi.install.area to one directory up from where the org.eclipse.equinox.launcher jar is located, but only if the directory which the launcher jar is located is named "plugins". See Main#getInstallLocation(). In the scenario above osgi.install.area=file:/d:/temp/zz_p1/cfg/bundlepool/ but simple configurator seems to think it should be osgi.install.area=file:/d:/temp/zz_p1/
The M2 build is apparently replicating to eclipse.org now. Instead of giving you a direct link, I'll give a link to a page that will contain the link, in case the final URL changes for any reason. This wiki page will have a link to the agent download when it comes available: http://wiki.eclipse.org/Equinox_Provisioning_Getting_Started#Step_1_-_Exploring_the_agent
Re comment #3, this is just a plain weird logic... I guess that we don't have much else to do than cope with it :-)
Another option is to set the osgi.install.area in the eclipse.ini to whatever you want.
Using the following in the eclipse.ini seems to work -Dosgi.install.area=file: This assumes that the eclipse.exe always sets the user.dir to the directory where the eclipse.exe is located. I'm not sure if that is always true.
> This assumes that the eclipse.exe always sets the user.dir to the directory > where the eclipse.exe is located. I don't think this is a safe assumption. I recently ran across a bug (jazz 30969) where the user.dir is different on Linux depending on how you launch.
Created attachment 79090 [details] patch This patch uses the -launcher to figure out what the osgi.install.area should be. The exe currently sets this in the native code. The thought is this is a more accurate way to figure out where the osgi.install.area is.
This patch does not work on the Mac because the executable is in a subdirectory eclipse/Eclipse.app/Contents/MacOS/eclipse
*** Bug 212067 has been marked as a duplicate of this bug. ***
Updating title to reflect the real issue.
See also bug 186151.
I have been playing around with that bug a bit and after a few fixes in p2 to handle some corner cases, it seems that the only satisfactory way to get scenarios like the one described in the initial bug working is to set osgi.install.area to '.' in the config.ini. That way, when started from the eclipse.exe we are sure that the base against which the paths are resolved (which seem to vary depending on which properties are set, which is to me the biggest problem for p2) is set to the install folder and thus have all of our paths computed properly. However even with that in place I can't get the scenario where the user points at the launcher.jar from outside the install folder working. For example the instlal is c:/eclipse/, the launcher jar is in c:/eclipse/plugins/ and the user types in c:\java -jar eclipse\plugins\launcher.jar I think that to get all the scenarios straight I will need Tom's and Andrew's help ...
Btw I'm not setting osgi.install.area to the actual folder because I want my install to be movable.
See also 217351
I have released changes in p2 for this. It all comes down to that p2 has to conform to what the runtime does and compute its path relative to the osgi.install.area instead of the installation folder.
