Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #431116 +++ See bug 431116 for background and details, but in general it is desired by community to have true "Mac packaging" for Mac distributions. I'm cloning this into cross-project list, since if "done for one" should be "done for all". If anyone knows of any reason this would be a bad thing to do, please speak up. Otherwise, for Mars release, we will investigate more concretely what it would take to get all our "Mac Distributions" to follow the standard "Mac Packaging".
I've updated the Platform version of this bug, bug 431116, with concerns about our ability to do this sort of packaging, given recent changes in Apple's "rules" about signing apps. (Where, basically, as I read it, sounds like just about anything under XX.app, can not change, once signed). And before anyone says "well, it works for me" please read all the histories and complications we've seen (across 3 or 4 bugs) where OSX "remembers" some things about some files, so it is not sufficient to base "correctness" on "its working". If anything, this might be one of the few cases I know of where "it is working" might actually indicate a bug. :)
You're probably right. What I've seen more often is Apps putting things like plug-ins into the Library family of directories. But we have examples of that where Eclipse is installed into read-only directories.
Changing title for the same reasons as title of bug 431116 was changed. A literal "one directory" will no longer work (with Apple's new signing rules) and even then, there's better/worse ways of doing things that could improve "shared installs" vs. "single user" installs, etc. The point being that is bug is about providing a "proper" Mac OSX bundle ... not "a single directory" as previous title suggested (and as least some of us, like me :/ thought was all that was needed).
Are people happy with the current .app distribution of packages or is this bug actually asking for dmg files?
I'm pretty happy with how things are laid out now. Moving things under the Contents/Eclipse directory gives a familiar feel while still keeping opening the .app folder as the main way for regular users to launch Eclipse. We can debate whether the Eclipse Installer is the right approach or not. In theory, we could package the EPP packages in DMG's so you simply drag them to the Applications folder to install. That would give a more native experience. But we are where we are at the moment.
Note that both EPP and Eclipse SDK will be published as DMG very soon (see bug 461670 and bug 106350)
sorry, I see this request only now. What this request means is to put the Eclipse data where it belongs (into /Library/Application Support). I'm talking about plugins and configuration folders, they cannot be inside the signed app bundle. Creating a DMG does not solve the data location issue; neither solves the codesign problem. The (correct) lcoation of application specific files is a huge issue for code signing; and Eclipse gets away by using a v1 signature which is deprecated already. Determining Where to Store Your App-Specific Files: https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/AccessingFilesandDirectories.html#//apple_ref/doc/uid/TP40010672-CH3-SW11 https://bugs.eclipse.org/bugs/show_bug.cgi?id=494293
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/171.
