Bundled app launcher changes

[Mike Swingler]

On Feb 10, 2012, at 5:48 PM, Igor Nekrestyanov wrote:

> On 2/10/12 4:49 PM, Mike Swingler wrote:
> 
>> On Feb 10, 2012, at 4:30 PM, Igor Nekrestyanov wrote:
>> 
>>> Because your app may depend on this structure.
>>> E.g. jre depends on presence bin , lib, etc.
>>> Granted Netbeans may be not "best" example of how to package java app as bundle on Mac but IMHO it is good example of complex app
>>> and good use case to investigate.
>> Why don't we focus on directing developers towards the simplest and most elegant solution,
> I do not see contradiction here.
> 
> The point i am trying to make is that it seem to make sense to optimize for scenario:
>   "i have my app working, now i want to ship it on Mac too. How do i generate bundle for Mac without changing my application?"

That attitude is why lots of Java apps suck on the Mac. A developer who gives no thought at all to understanding the conventions and norms of the platform shouldn't bother trying to port their app. It will be rejected as an unacceptable experience by real users.

This is not an abstract philosophical point - NetBeans uses a shell script as it's primary executable, which then sub-invokes the java binary. This seemingly "rational" decision to "be like other platforms" means that it can never be associated with a document extension type. If they were to bend their deployment to use this new stub that Greg is developing, they would then be able to receive open-document AppleEvents.

> And expect that most of the people will use some kind of IDE to develop their projects. IDE typically generate own cross platform "bundle" for distribution
> that developers test (e.g. dist folder in NB). It seem reasonable to assume this is starting point for packaging the app.

Cite an example of one of these cross-platform bundles produced by an IDE, and why it is relevant to Mac application deployment.

>> instead of over-engineering around their backward layout structures?
> 
> So, we think that the only reasonable way to structure bundle is to have flat set of files under Home?

A flat set of files under a Home is the most straightforward thing to implement in a bundler in the here and now, while leaving ourselves the flexibility to enhance the design later, demonstrated to be actually necessary by real use cases. This is a new architecture, and backwards compatibility with Apple's previous bundled app structure or any other deployment technology for any other platform is a non-goal.

>> If they want an unmaintainable bundle structure, hand assembling their Info.plist is a cost (one of many) they have to pay for running off the rails.
> Could you please clarify "unmaintainable" part?
> From the "bundle wrapper" standpoint it is blackbox, it only knows how to find main jar and runtime to use.

Once an app is bundled, it is possible that an IDE that produced it will want to re-open it, perhaps make tweaks, and keep the Info.plist file in sync with it's changes. After making changes, it may have to re-codesign the mach-o executable contents. If there is an arbitrary hierarchy inside the app bundle, that is another axis of complexity for the IDE to manage. If it's expected that an IDE should edit an application structure with some backwards legacy layout, that just makes the whole "edit an app" feature less likely to be implemented, since it will be bogged down in an unnecessarily complex design.

I hope this clarifies how we wish to keep our options open for future features by focusing on a tight, narrow, focused design,
Mike Swingler
Apple Inc.