Community
Participate
Working Groups
Created attachment 190861 [details] Experimental patch (not suitable for inclusion as is) As I alluded to in bug 338148, it would be nice to have some mechanism to provide a custom Info.plist for MacOS X apps. The Info.plist is a declarative manifest that's used by MacOS X to hook the app into various OS facilities. Other OSs have similar files (e.g., the freedesktop.org .desktop files [1]) Currently the only way to provide a custom Info.plist appears to be to be by providing a modified variant of the org.eclipse.equinox.executable feature. I say "appears" as it's hard to get this to actually work as it requires publishing root files which doesn't seem to be supported by the p2 FeaturesAndPlugins publisher (bug 327828). Although it should be possible for interested users should be able to maintain and publish a modified executables as part of their build, it complicates the system integrators scenario as described in bug 327828. I've hacked up the p2 product publisher to allow specifying a plist to the launcher configuration section of a .product file. It looks something like: <launcher name="sample"> <macosx plist="Info.plist"/> <solaris/> <win useIco="false"> <bmp winSmallLow="test/icon.bmp"/> </win> </launcher> I've attached an experimental patch to add this support to the p2 BrandingIron (relative to the p2 publishing incubator). It is not suitable for merging as is: as it required hacking a number of classes interfaces to get the plist information to the p2 BrandingIron. If we go forward with this approach, we should look at extending ProductFile, ProductFileAdvice, and IBrandingAdvice to expose and communicate this information in a more friendly manner. [1] http://freedesktop.org/wiki/Specifications/desktop-entry-spec?action=show&redirect=Standards/desktop-entry-spec
Thinking about it, wouldn't a P2 touchpoint action be a more elegant and extensible way of modifying Info.plists? I have a scenario in mind where a bundle wants to register a URL handler in the system (see bug 351303). On MacOS, this means to augment Info.plist, on Windows this a change in the registry, and on Linux it's some other system file. Such a specific touchpoint action (e.g. 'registerUrlHandler') would allow many bundles to contribute to a standard Info.plist file. The .product approach on the other side would allow for a completely deviating Info.plist, at the price that it's not extensible. @Brian: what do you think? Which approach would cover your scenario?
(In reply to Christian Georgi from comment #1) > Thinking about it, wouldn't a P2 touchpoint action be a more elegant and > extensible way of modifying Info.plists? It can only be created and modified before signing (and shipping), though.
> It can only be created and modified before signing (and shipping), though. Well, Info.plist of the Eclipse product is not signed because I can happily modify it w/o issues. I think this was done on purpose to allow such late modifications. But yes, with signed Info.plists install-time contributions are not possible. The touchpoint action would just fail silently in such cases.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
