Community
Participate
Working Groups
using 3.7m6 When exporting the simplest possible product from the workspace I get the following if the executables feature is present in the target. Deleting the executables feature eliminates the problem. An error occurred while installing the items session context was:(profile=profile, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null --> [R]org.eclipse.equinox.launcher 1.1.1.R36x_v20101122_1400, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction). Error while loading manipulator. - create a new product with no product/application - add org.eclipse.osgi to that Dependencies tab - export (and generate metadata) - observe the error described - remove the executables feature from the target - export (and generate metadata) - notice that it all works swimmingly Note that I was targeting 3.6.2. It works when targeting 3.7 (from the "updates" p2 repo). Not sure if that is because the thing it was looking for was in the IDE install or because there really is something different. The log has the following in it java.lang.IllegalStateException: The framework persistent data location (/temp/example/eclipse/Eclipse.app/Contents/MacOS/configuration) is not the same as the framework configuration location (/temp/example/eclipse/configuration). at org.eclipse.equinox.internal.frameworkadmin.equinox.EquinoxManipulatorImpl.checkConsistencyOfFwConfigLocAndFwPersistentDataLoc(EquinoxManipulatorImpl.java:65) at org.eclipse.equinox.internal.frameworkadmin.equinox.EquinoxManipulatorImpl.loadWithoutFwPersistentData(EquinoxManipulatorImpl.java:348) at org.eclipse.equinox.internal.frameworkadmin.equinox.EquinoxManipulatorImpl.load(EquinoxManipulatorImpl.java:319) at org.eclipse.equinox.internal.p2.touchpoint.eclipse.LazyManipulator.loadDelegate(LazyManipulator.java:54) Seems like a Mac-specific thing where there is wrong assumption about the location of the configuration dir... Marking as Major to look at before 3.7 ships
Jeff, did the export leave you with a p2 repository? Can you try performing a director install of the product using that repository? I expect that this bug belongs in p2.
Created attachment 193773 [details] example repo Yeah, when I first was writing up the bug it was in p2 but then it started to feel more like a publishing/build problem... anyway, we can move it if needed. The export does produce a repo but installing with the director still fails. The repo itself is structurally ok but the contents do look a little odd. Examples of oddness... - The metadata includes equinox.executables.feature.group IU - Artifacts repo does not include the executables feature itself - the artifacts repo has binary zips for launcher root files for every platform (I did NOT do a multiplatform export) Correction on the previous comment: The problem DOES happen when targetting 3.7 with the whole Equinox Target Components feature in the target (from the 3.7 milestones repo) Also, I'm not sure it is just the Executables feature. I think it is more the launcher and launcher fragments. Whatever causes the "Multiple platforms" checkbox to appear in the export dialog. I've attached the exported repo to this bug. The product is dead simple. Just set the id/version and add org.eclipse.osgi then export.
Running on linux cross platform export to mac works fine for me. I do see a problem with the attached repository, the binary artifact example.product_root.cocoa.macosx.x86_64_1.0.0.201104202214 contains launchers Eclipse.app/Contents/MacOS/eclipse but the chmod action in the metadata is chmod(targetDir:${installFolder}, targetFile:eclipse.app/Contents/MacOS/eclipse, permissions:755) which doesn't match. This causes a failure on linux when trying to install from the attached repository. This is a problem that will likely surface when the metadata is generated on a non-case-sensitive platform and consumed on a case-sensitive platform. I raised bug 344623 for this. This is not the problem Jeff was seeing.
Getting past the problem in comment #3 (which you probably wont see on windows or mac), and the real problem is that p2 is using a bad value for osgi.install.area, which leads to a bad config area and then the IllegalStateException. I don't know what difference the presence or absence of the executable feature is making to the metadata to make p2 get this right sometimes.
Created attachment 194623 [details] patch The problem seems to be EclipseLauncherParser#read. The "launcherFolder" here is just the parent folder of the executable (Eclipse.app/Contents/MacOS). When producing a brand new install, the eclipse.ini does not yet contain -startup (or -install) because the IU fragments that add those arguments have not been processed yet. In this case (we also don't know the framework jar), the launcherFolder ends up being used directly as the osgi.install.area which is incorrect for the mac.
Pascal, can you please review for RC1
Great catch in comment 3! Thanks. I took a quick look at the patch and it feels good. I did not dive into the details of what ParserUtils.getOSGiInstallArea() does (this is for the case that eclipse.ini does not have anything interesting in it)
I can confirm that this patch fixes another problem I just encountered. Somehow I have an app install that does not have -startup. It runs just fine etc but without this fix you cannot update it as the configuration location comes back wrong and so does not validate in the Equinox manipulator.
patch released.
