Platform-releng/Issues related to Mac App installations
This page is intended as a "transition" page as our Eclipse SDK is made into a more standard "Mac App", rather than having a non-standard (for Apple users) "directory layout". It will change over time as as issues are addressed or documented elsewhere, and will become obsolete with the Mars release. (Feel free to edit, with tips or new information, and as new problems are found please open bugs with them blocking the main bug (bug 431116) that tracks issues and progress.
Eclipse SDK as a Mac App -- Information for Users
Mars Update Warning
For Mars Release (Eclipse 4.5), you can not "update" from an existing "directory layout" installation. You must download a fresh version, and start with that. In fact, as of M6, there is nothing to prevent the update from being attempted, but will leave you with a broken installation. (Watch bug 462282.) In fact, even with the final Mars release, you will not be able to "update", but the plan is to prevent it from happening, and give a proper instructions to users if they try.
Recovering from a broken installation
In the event you did try to update, before the protections are put in place, this is the procedure to "recover" your previous installation with minimal effort. (Thanks to Markus Keller, who provided this outline, in bug 462282#13.)
- Get a fresh download of M6 (or later) of the App you intend to use, such as from Eclipse Project Downloads to create a fresh installation.
- From the downloaded tar file, extract the Eclipse.app to the location where you would like it to be.
- Launch the fresh Eclipse.app
- Choose File > Import... > Install > From Existing Installation
- Click Browse... and open the folder that contains your (broken) Eclipse.app
- Click Select All, Next, and Finish the import
- After a restart, all your plug-ins are available and work as before.
Eclipse SDK as a Mac App -- Information for Adopters
As it turned out, none of this "shared installs" concept was implemented and does not seem necessary, so far. That is, once the signed app starts, then it can change its internal structure, and while that does break the signature, Mac OSX remember that it was signed, and allows it to run.
One change, that will be coming in M7, from previous "directory layout" is that the "Eclipse App" will behave similar to what is called a "shared install" (or sometimes called "split install"). This is primarily due to the way Apple apps are "signed" where is is expected that nothing "under" Eclipse.app will be changed (or, if it is, it will "break" the signature).
This means that as you install new plugins, or make customizations, they are not saved "under" Eclipse.app, but are saved under
some place like ~/Library/Application Support/? (or, perhaps ~/.eclipse/) (See (bug 431116#c18.) So providers or adopters may want to set their "Eclipse.app" folder to be "read only" to be sure they have no hidden assumptions about where data is located on the file system.
Some of he changes to produce this "Mac App" layout is in the p2 publisher. Some is in the Tycho Builder. At the time of this writing, Tycho 0.23.0-SNAPSHOT must be used to publish "Products" with the Mac App layout. At the moment this is the only layout possible, and the older "directory layout" is not possible. (Watch bug 461606.) To get the correct layout, though, a slight change to "product" pom files is required -- you will need a "rootFolders" element. Where previously you may have had
<id>materialize-products</id> <goals> <goal>materialize-products</goal> </goals> <configuration> <profile>SDKProfile</profile> <products> <product> <id>org.eclipse.platform.ide</id> <rootFolder>eclipse</rootFolder> </product> </products> </configuration>
You will now need
<id>materialize-products</id> <goals> <goal>materialize-products</goal> </goals> <configuration> <profile>SDKProfile</profile> <products> <product> <id>org.eclipse.platform.ide</id> <rootFolder>eclipse</rootFolder> <rootFolders> <macosx>Eclipse.app</macosx> </rootFolders> </product> </products> </configuration>
NOTE: even though the original reason for specifying "Eclipse.app" explicitly is no longer true, without it, you get a lower case "eclipse.app" and we have decided it is preferred, if not necessary, to keep it upper case ("Eclipse.app"). See bug 492822.