Bugzilla – Full Text Bug Listing
| Summary: | Export failure on Mac with executables feature present | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Jeff McAffer <jeffmcaffer> | ||||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | aniefer, pascal | ||||||
| Version: | 3.7 | Flags: | aniefer:
review?
(pascal) |
||||||
| Target Milestone: | 3.7 RC1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jeff McAffer
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. |