Community
Participate
Working Groups
Most apps have resources that are built-in to the .app bundle, as opposed to outside the file itself. Apart from anything else, this makes drag-n-drop install of the application much easier. Eclipse goes against that philosophy; the download includes a folder that contains the Eclipse.app, a separate folder for plugins, a separate folder for features, and a few other files/directories. In order to resemble a Mac app, the plug-in/feature/config folders should either be: a) Packaged within Eclipse.app, under Contents/Resources (see http://developer.apple.com/ documentation/MacOSX/Conceptual/SystemOverview/AppPackaging/chapter_45_section_3.html for more info) b) Installed into /Library/Eclipse/ or /Library/Application Support/Eclipse The difficulty with part b) is that it would still involve a separate directory structure. The only way of automating this would be to have a Mac specific installer (.dmg) which may not be possible to create on the Eclipse build environment automatically. Part a) seems a logical choice, but then stops the user directly being able to see the plugins/features directories. Of course, there is nothing to stop them being symlinked to within the .app bundle if required.
Two years ago, we had the plugins directory inside the app bundle and got PRs against that because users installed new plugins quite frequently and moving them into the hidden app bundle wasn't obvious. This was discussed on the SWT mailing list. SO we decided to move the plugins and feature directories outside of the bundle. Yes, there is some naive support for plugin management in Apple's Get Info dialog, however I'm not sure that the associated UI makes plugin management easier (the option to disable is in fact quite dangerous since it does not understand anything about plugin dependencies and can easily result in a non-functioning eclipse). But I agree, that for RCP applications it would make sense to have plugins hidden in the app bundle (and my RCP app builder already supports that).
BTW, other professional Mac applications have their plugin directorie outside of the bundle too (e.g. Photoshop, InDesign, etc.)
...users installed new plugins quite frequently and moving them into the hidden app bundle wasn't obvious. Why should it not be possible to use the Update Manager to do the work for them, rather than having to have the users copy-and-paste solutions? From a 'dumb' user's point of view (would dumb users use Eclipse, though ...) copying into the same directory may be equally as dangerous. For example, open a (say) zip file containing the plugins, and drag-and-drop the folders across -- Mac's original implementation is to replace the entire folder, rather than merge it. So you'd end up with a 'features' and 'plugins' directory that *only* contained the new plugins, and your system would be equally as broken. You'd have to open the 'plugins' and 'features' directory individually, then copy the contens of the new- plugins and new-folders directiory separately. This also doesn't rule out having the plugins and features installed in the .app bundle, whilst having symlinks to the plugins and features directory outside. You'd still have to open the plugins and features directories individually, but you'd get the advantage that whenever you upgraded Eclipse, you'd also get the standard version of all the plugins without having to worry about dependencies (or even run with two apps in the same directory). So I agree that at the time, the original decision to have them outside was correct, but now I think there are better solutions available, especially with the update manager working. Your point re: Photoshop et al is well made, though. But note that upgrading such a product there does often involve trashing the entire folder and starting again. Perhaps if the idea of leaving the plugins and features where they are will remain, it would be better to build the 'eclipse' download with a single 'Eclipse' folder, and have a suitable .DS_Store or .Icon? or whatever to closer match products like Photoshop. At least, that way it will give the user the opportunity to only copy one folder over instead of many.
Moving to the releng team, since it is "only" a packaging problem. Sonia will some investigation to see if we can behave like a nice mac app. Andre if you think we should not try that, let us know.
Given that Eclipse can handle having plugins and features stored in multiple locations now, why not have the core Eclipse plugins bundled in the .app structure, but also have /Library/Application Support/ Eclipse (and, indeed, ~/Library/Application Support/Eclipse) on the search paths? That way, installing a new feature/plugin doesn't necessarily have to be done into the Eclipse.app's core set directly; it could be done on a per-system or per-user setting.
Alex, have you already played with that idea? I like it, but I don't think the links folder will be able to refer to a user specific folder, and we can't have an installer (even a dmg) for now. What happens if the links file exists but the folder does not exists? If you have explored, please attach the necessary files.
Please reopen with neccessary files as requested in comment #6
I'd just like to make it clear that my blog post http://alblue.blogspot.com/2006/04/eclipsemac-maclipse-and-maclipse-lite.html wasn't in any way a dig at this bug. I meant that such a repackaging wasn't likely to happen for the 3.2 timeframe (though it would be great if it did) but hopefully such a reorganisation might be possible for 3.3+ I made the download available from sourceforge (http://sourceforge.net/project/showfiles.php?group_id=142821&package_id=186320&release_id=407191) to show how the Mac.app can be reorganised to suit a better style of Mac application, since there were comments at the Mac OS X BoF at EclipseCon and I promised a working demo of it. By the time I got back, it made sense to wait until the 3.2M6 drop to come out. It's not really the comment at #6, because that was talking about having multiple extension links into user-specific directories (hence, no files attached). Although you can add such extension links manually, you have to specify it and there's no standard Eclipse mechanism for ensuring that the directories on the user's directory exist. Of course, you could achieve this with a Mac OS X specific plugin to do setup; but I'm not sure that's in the spirit of Eclipse. What the packaging did is follow the initial bug report part (a) instead of part (b). Andre's comments are still valid; but as Eclipse's ecosystem is moving more and more towards an Update-Manager driven process, it's going to be less and less necessary to have to get into the plugins/features folders. You could solve both problems by having: 1) Move the features and plugins inside the .app 2) Ship the deployed .tgz with soft links from plugins/ -> Eclipse.app/Contents/Resources/Java/plugins/ That way, if someone just wants to copy the .app bundle to /Applications, that's all they'll see. If they want to drop stuff into the plugins directory as well, they can copy the symlinks too and have a very similar view to what they have at the moment. Of course, you might also want to copy things like startup.jar and eclipse(.exe) as well. I'd like to make it clear that I disagree with Denis' comments on his blog, and this is not extortion about this particular bug, and that at the earliest this wouldn't be addressed until 3.3 given the current state, possibly even longer. Whilst I would like this bug to be reopened against the 3.2 stream, I'm leaving it as RESOLVED WONTFIX so that you can decide the most appropriate course of action for this bug.
I would also like to see a proper repackaging of Eclipse for MacOS X. I suggest this to be done by altering the RCP product export code so that all RCP applications will benefit of it. For instance, the JCommander (http://jcommander.sourceforge.net) RCP project that I am leading has received several feedbacks from Mac users that the MacOS X package looks weird.
I imagine that at this very moment the Eclipse team is enjoying a well deserved beer to celebrate the Callisto release. So while you're all partying, I'm going to make a fix request. That's how I show my love<g>. Seriously, I hope this defect can re-opened and made a priority for 3.3. I think we can make a distinction, though, between how Eclipse itself is packaged and how RCP apps should be packaged. Much of the discussion of adding plugins to a preexisiting install apply more to Eclipse (or maybe to an RCP app targeted at a technical audience). Would it make sense to open a separate defect that specifically addresses RCP packaging for Mac OS X? My RCP application (www.marketcontours.com) is targeted at a non-technical consumer market which does not want to hear or see the word "plugin" ever. Like many other applications, it is trial-ware, and I can't afford to lose potential customers because the distribution is non-standard (non-standard == scary, spyware, buggy). If RCP apps are going to succeed in the consumer Mac OS X space, it's essential that the distribution be in the format that Mac users expect. Thanks for listening.
Indeed, i would like to see this implemented as well. I am wondering though if anyone tried or considered to reorganize the application bundle structure of your RCP application to match a single app bundle through an ant task that is executed right after PDE build? Maybe Alex can give us some hints what kind of changes are involved to basically transform the standard Eclipse directory structure into a single app bundle? I would be surprised if this couldn't be automated. It would certainly be nice since there are probably a lot of guys out there who can't immediatly build their RCP applications based on 3.3 milestones or later when this is (hopefully) changed.
In response to comment 11, I've been doing this type of post-processing to create a properly structured app bundle. I've written a short article describing the process: http://www.rcpquickstart.com/packaging_an_rcp_application_for_mac_os_x
I've read all comments on this bug and I fail to agree that presenting a non-conforming application structure is a solution to the outlined problems. I have limited experience with Mac OS X but I know for sure that the first thing that's struck me about Eclipse IDE when installing it on this platform is that it doesn't come as an .app package that I can just drag in my "Applications" folder and I thought that it showed lack of professionalism in this application. Now the problem is not really in the non-conforming Eclipse IDE. It's a development tool after all so people installing it will likely have the appropriate skills to overcome the unusual bundling. The real problem for me is that the RCP application that we are building and distributing is not a development tool and our clients are not expected to have such a vast computing background. I don't agree with the explanation that users find it hard to find the "plugins" directory. Why would they in the first place go fiddling with it? If they are software developers, then they have the necessary background to locate it. And if the users are not this much technically/computing aware, then why in the name of God would one want them to install new plug-ins by extracting from archives, copying to specific folders. I think one will want to present them the Update Manager (though it's also complicated) and let them do the work in a much more easier way.
Can we get this bug reopened? I think it's clear that there are a number of Mac developers -- particularly in the RCP space -- who would like to see this fixed properly to be a real application. I think a lot of the comments on the SWT mailing list probably don't apply, since it was before the days of Eclipse RCP, and also at a stage where the update manager wasn't perhaps as widely used as it is today. In any case, it is now possible to sort out things like symbolic links during the build of the Eclipse RCP drop, so it would be possible to provide symbolic links from 'features' -> 'Eclipse.app\Contents\Resources\features' for those that did want to have that functionality; yet the .app bundle could be dragged into any Applications folder without needing those symbolic links if they weren't necessary. In short, I think the objections are outdated and were probably made by people who didn't understand how Mac applications should be packaged; now that the advent of RCP applications across all platforms are pushing the boundaries towards better installs for specific platforms that it's time to readdress this bug.
Patrick, congratulation on your document. It will be useful to a lot of people out there. The problem itself is not in platform / releng but in PDE build that likely does not have all the support required to create such a shape. It would be great if one of you could open a bug and spend some time working on a fix (note that we would help with any questions and I think some code attach to another bug could be useful there too). Thanks in advance.
I don't think this bug should be left as WONTFIX. It makes a strong statement that this is never going to be addressed. And, re comment #15, if a bug is to be created to deal with fixing this issue, then using the current bug with all its votes and Cc members is the rational thing to do, rather than opening a new one. If Platform/Releng is the wrong assignee, then by all means change it to something else, but don't just mark it as WONTFIX if it's not in your area to fix. > The problem itself is not in platform / releng but in PDE build that likely > does not have all the support required to create such a shape. This seems to be an untested hypothesis, rather than a declaration that it is impossible. In fact, there doesn't seem to be any reason why it's not possible; after all, you can change the gather folder for the Zip when exporting plugins (e.g. the prefix 'eclipse' is supplied in this way) so there's no reason for a Mac build it couldn't be made to utilise 'Eclipse.app/Contents/Resources' instead. I have heard that there are hard-coded expectations in the releases engineering process that expects there to be a file called 'eclipse' generated. This doesn't appear to be a requirement for PDE -- since it will generate whatever when run -- but rather in the scripts/code used to launch PDE as a yardstick for whether it was a successful build or not. However, I don't know if this restriction is still true any more. Other comments -- like the idea of having ~/Library Support/Eclipse/Plugins -- are not central to getting the features and plugins moved inside the Eclipse.app, which after all, is just a folder as far as the Mac filing system and any other code is being used. Also note that whilst it may be an idea to support symlinks from 'features' to 'Eclipse.app/Contents/Resources/features' may be useful for people expecting a different packaging structure, it's not necessary to enable the movement of the 'features' and 'plugins' inside the .app bundle. It would almost certainly be better to ship the Eclipse.app without any other files at that level anyway (including eclipse) although there are arguments for the license and/or similar readmes to be made available there. I'm more than happy to help working on patches to support this solution, but I feel it's going to take contributions from both PDE build and also the releng team to make it happen. I therefore suggest that we keep this as OPEN and we can use it to discuss what needs to be done and hopefully move it forwards. Alex.
Let's assume that this bug is important enough to get fixed. I can contribute some time towards it. The PDE export is (probably) capable of generating the right structure, but it will be different for Mac OS X than it will for other platforms. How can we configure the build so that certain values are used instead of a default on Mac systems? I.e. is there any way of doing a platform override for the build, or are they all done on one build? (If so, how do platform-specific features like SWT get weaved in?) Given that PDE build can be customised (e.g. the gather target would only need to have an Eclipse.app/Contents/Resources/Java prepended) it doesn't seem like it would be difficult to do, but I don't know what to submit patches against because I don't know where releng kicks off the build for the Mac systems.
I think the remarks in comment #15 still apply and changes need to be made to PDE build to support this shape. That being said, the way that the build assembles the mac drop is like the rest of drops. The build generates a master feature of all the plugins and features used in the build. We then sign and pack this master feature. We then create a feature consisting of root files. See org.eclipse.releng.eclipsebuilder/buildAll.xml main target We then use the packager to slice and dice the master feature into the appropriate drops. This is the packageEclipseDistributables target in the same file. The packaging files for the sdk are in org.eclipse.releng.eclipsebuilder/eclipse/buildConfigs/sdk/packager
I second this. I am trying to release ForeFlight for OS X and am struggling with the creation of a proper eclipse distribution for OS X. The problems I am experiencing: - The icon does not bounce in the dock - Even if I manually make an .app version, like described here (http://www.rcpquickstart.com/packaging_an_rcp_application_for_mac_os_x) it does not work properly if set to "leave in dock" - it spawns multiple dock icons at launch time, one of which has a name of "java" - the info.plist files created by the current exporter sometimes have their own vm flags, which end up replacing those that go in the application.ini file.
dock icon bouncing works only from 3.3M5, I have built for myself a simple bash script which does everything is needed to transform a 3.3M5+ Mac tar.gz distribution into a proper application bundle and puts all configuration files into ~/Library/Application Support/Eclipse, maybe if there is any interest I could distribute it as an automator droplet application
The script/automator action would be nice to see - I'm also producing a cross platform RCP and struggling with making things Mac-like. (In reply to comment #20)
I am also producing cross-platform RCP applications. I would personally prefer that the behavior of the Eclipse platform itself be similar to the larger "suite" applications. However, I would like the option to package the plugins and features folders of my own RCP applications inside the app bundle since they do not always provide extensions for other plugins. (In reply to comment #21)
+1 for an export setting or a packaging script for RCP apps which put everything in a *.app folder. Eclipse should also be packaged like this since the best way to add/remove features is to use "update manager" and "manage config" tools.
Does the new work on provisioning have any affect on this issue? Also, consider the case where an IT group provides a common, read-only, Eclipse install for it's users. If a user wants to install their own plug-ins, they either have to ask the IT department which will most likely say no, or download their own copy of Eclipse, install all of the common plug-ins installed by IT, and then add their plug-ins. As far as the Mac is concerned, I really like the idea of being able to bundle the plug-ins in the .app with the option of installing additional plug-ins in the various Application Support folders.
For those interested by a packaging script, I've just came against a google-code-hosted MIT-licensed project: http://code.google.com/p/eclipse-osx-repackager/ HTH and thanks to the project owner! Romain.
I'm not sure where P2 is in the update list, but this sounds like something the P2 install should be able to do nicely.
p2 bugs go in equinox p2
Moving to Equinox - can't see P2 form a component list (maybe I have to do one at a time?)
+1 this sounds like a very valid enhancement request.
This will not be done for 3.5. I have been playing with various arguments of p2 to set it up but without success despite being very close.
Hi, I'd just like to offer few cents of my own pov (as an Eclipse user) on this. As a user of both Mac and Windows platform, I must say, that I really dislike the way Eclipse is packaged on mac - it just feels a little ... sloppy compared to all other apps. I would also love to see the mac provide a sinlge Eclipse.app bundle that could be easily dropped to Applications folder and bedone with it. With the new p2 provisioning and new folder layout, I do not see why should I not be able to just install new features via via new update manager (directly into the Eclipse.app folder) or if I indeed decide to "drop in" few manually installed bundles/features, use the "dropins" folder feature available since 3.4 release. I don't really know if this is possible, but I would suggest using "/Libraries/Application Support/Eclipse" and "~/Libraries/Application Support/Eclipse" as the dropins folders (or symlinking those) for the Eclipse.app instances. This way, I could still install plug-ins and features manually if I so wish and in addition I would have ability to install 3rd party plug-ins for all users or just myself...
> I don't really know if this is possible, but I would suggest using > > "/Libraries/Application Support/Eclipse" and > "~/Libraries/Application Support/Eclipse" > > as the dropins folders (or symlinking those) for the Eclipse.app instances. > > This way, I could still install plug-ins and features manually if I so wish and > in addition I would have ability to install 3rd party plug-ins for all users or > just myself... > You could make that work today (there's a special argument to specify where the dropins are supposed to be) but then you will have all your Eclipse instances use the same dropins. That won't work for people like me who have two or three different versions of Eclipse and different specializations in the dropins. Eventually it would be something to consider for a commercial application.
(In reply to comment #32) > You could make that work today (there's a special argument to specify where the > dropins are supposed to be) but then you will have all your Eclipse instances > use the same dropins. That won't work for people like me who have two or three > different versions of Eclipse and different specializations in the dropins. > > Eventually it would be something to consider for a commercial application. > That's exactly my point - we could make that work today. If the dropins folder property can be so easily specified, those of us, who need multiple different profiles, could also perhaps augment their dev environment with appropriate settings On a related but somewhat different subject - I was recently discussing with someone how the problem of multiple eclipse installations could be solved by using bundle pooling and custom dynamic bootstrapping of eclipse with appropriate profile. With bundle pooling one could have the entire world of eclipse plug-ins in a bundle pool but only bootstrap with those enabled that are allowed by the chosen profile. This would severely cut down the wasted disk space that is required for maintaining multiple installations of eclipse with sometimes overlapping set of plug-ins/features. If done right, the launcher could for example in addition to selecting your workspace ask you to choose your "eclipse profile" (and possibly remember to bind the profile to the workspace). This way we would not need to install multiple instances of Eclipse and still gain the benefits of having separate IDE configurations for "Java" vs "J2EE" vs "Modeling" development...
(In reply to comment #33) That's a very sexy idea - looks like it doesn't apply to Mac only. I would make that a separate request for enhancement. Maybe there's already a bug for it ?
(In reply to comment #34) > (In reply to comment #33) > That's a very sexy idea - looks like it doesn't apply to Mac only. I would make > that a separate request for enhancement. Maybe there's already a bug for it ? > None that I know of... ... If you open a bug report for it - just give me a bug number ... I'd love to chime in to the brainstorming...
Going back to the original issue here. (In reply to comment #32) > You could make that work today (there's a special argument to specify where the > dropins are supposed to be) but then you will have all your Eclipse instances > use the same dropins. That won't work for people like me who have two or three > different versions of Eclipse and different specializations in the dropins. > > Eventually it would be something to consider for a commercial application. > As I said before, exactly my point - we could make this work today so that it would work out of the box like any mac user would expect. Since the mechanics of the said customization already exist, why not make the default for mac users to conform to their expectations and for those of us who really need to deploy several versions of Eclipse, as You said yourself, it is already possible to specify where an eclipse looks for it's dropins folder...
We certainly intend to keep supporting bundle pooling as described as comment #33, but I suspect we would get resistance to making this the default. Many people like the isolation of each app being installed separately, and being able to completely delete and reinstall apps individually. In any case you're welcome to enter a bug report for further discussion.
How does LotusNotes deal with this issue? It is installed as a normal Mac application?
created new RFE for dealing with idea in comment 33
(In reply to comment #39) > created new RFE for dealing with idea in comment 33 > That would be bug 282542 sorry for bugspam...
For those looking for a quick fix on this one, here is a nice script that does the job: http://github.com/andreyvit/yoursway-eclipse-osx-repackager/blob/master/EclipseOSXRepackager
*** Bug 306211 has been marked as a duplicate of this bug. ***
*** Bug 265309 has been marked as a duplicate of this bug. ***
I spent some time looking at this today and I think that the most expedient way to address this is to move everything (plugins, features, configuration, etc) into the MacOS folder or the Resources folder. It surely does not match the shape recommended by Apple, but it has the advantage that the resulting Eclipse layout matches the one found in all other OSes, which therefore limit the number of surprises we could run into (e.g. ppl making assumption about file layour). https://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW1
I think that .apps are opaque enough that any layout would be acceptable, and the consensus above seems to agree (given the number of scripts linked above - and inevitably built internally and never published - that do exactly this.) I think we just want Eclipse to be distributed this way so that we don't have to do it ourselves.
What I would like to see is a new product build option (in the settings, or build properties, or something) where the "install" directory could be easily packaged inside the app bundle. The default would still be to package the app with plugins/features/configs as sibling directories as before, but additionally allow some setting that would put those directories in Contents/Resources as recommended in this bug.
I've made some progress on this and here is an outline of the layout and how it would work. * Layout The layout for a mac application would be the following (this is different than what I first thought in comment #44). Eclipse.app/ configuration/ config.ini Contents/ MacOS/ eclipse eclipse.ini plugins/ ... p2/ ... dropins/ ... It basically treats the .app folder as the install folder and lays out all the files in it. The reason for keeping the files at the root is that any script or tool that today knows where to find files would not have to be modified to be made Mac aware. Also from a runtime point of view, all platforms have the same layout which is convenient for people doing path math. * Generating this layout First, the support for this new layout requires changes to the metadata. The generated p2 repositories will include additional IUs / CUs that take care of the new layout (mostly unzip the executable at the right place). The generation of these IUs will be done automatically at build time when metadata is generated for macos. From an install point of view, the "bundled" layout will automatically be enabled when the install folder specified as argument of the director application will end with .app (for example -destination /Users/pascal/tmp/Mail.app). If instead the folder does not end with .app, then the old layout will be generated.
Rejoyce my friends. This is now fixed in Juno! Note that this work has been financed by http://manumitting.com/ Details on how to use this have been captured in: http://prapicault.blogspot.ca/2012/05/eclipse-based-applications-as-standard.html
closing.
(In reply to comment #48) > Rejoyce my friends. This is now fixed in Juno! > Note that this work has been financed by http://manumitting.com/ > > Details on how to use this have been captured in: > http://prapicault.blogspot.ca/2012/05/eclipse-based-applications-as-standard.html Thank-you to both Pascal and Brian! I've tested this out last night and it works really well.
I use headless PDE Build to create RCP distributions for 3 different platforms plus a p2 repository all at once. Is there a way to make this setup produce .app layout for Mac? If not then what is the correct approach?
Hi there, I've just tried this new capability and it works well up to a point. Indeed, in generated layout, the 'features' folder is missing. That leads to the About dialog to not display correctly branded features. In addition, 'Installation Details/Features' tab is empty. Does anyone experience that ? Regards, Stephane. Config : I produced the build through PDE scripts and I ran p2 director in addition as described in the Pascal blog. My eclipse to run all the stuff is a Kepler release build id :20130614-0229. (In reply to comment #48) > Rejoyce my friends. This is now fixed in Juno! > Note that this work has been financed by http://manumitting.com/ > > Details on how to use this have been captured in: > http://prapicault.blogspot.ca/2012/05/eclipse-based-applications-as-standard. > html
