Bundled app launcher changes

Mike Swingler swingler at apple.com
Fri Feb 10 19:49:58 PST 2012


After a little more thought, a more detailed response is required:

On Feb 10, 2012, at 6:42 PM, Igor Nekrestyanov wrote:

> On 2/10/12 6:09 PM, Mike Swingler wrote:
> 
>> 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.
> I do not follow this.
> I do not see anything in what i said that implies that app will not follow best practices.
> 
> How having multiple jars or complex directory structure inside the bundle change anything in the user experience??

It was a rant against the general attitude of "oh just push a button to make the Mac version", and not about the specifics of deep vs. shallow filesystems.

>> 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.
> I agree shell script is wrong entry point.
> Packaged as "proper" bundle it will have start with whatever it is Main class.
> 
> But it will not make it to me flat structured and i do not see how making it flat helps in any way.

Agreed. Flat vs. deep is completely orthogonal to the end user experience.

>>> 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.
> Any application that uses libraries in NB will have
>    dist/app.jar
>    dist/lib/lib.jar
> structure and correct classpath in the app.jar.
> 
> This is what developer test when he develops.
> I do not follow why reinvent it and say that it has to be restructured for Mac ...

I think it is beneficial to bend new applications to use simpler and more elegant deployment patterns. This helps the tools that create and manage them over their lifecycle easier to develop. Just because NetBeans does it one way is not a reason to introduce complexity into how this app bundler tool works for it's 1.0 version.

>>>> 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.
> Why ignore other platforms for parts that do not impact deployment on Mac?
> This forces people to develop apps in the different way for different platforms.

This is only a concern for legacy apps. As a rule, new apps are always more important than old apps, because they break new ground and push the platform forward.

Flat vs. deep resource location isn't going to be the show-stopper that blocks converting a legacy NetBeans-based app to using this new stub either...NetBeans own launcher will be, and it will just have to be adapted to whatever the new model is which isn't a shell script. Frankly, they can keep using a shell script forever for "old style" apps, if that's easier for them.

> I agree with need to tune application for platform to follow best practices on the platform.
> But why add complexity to development process if it has no impact on the result UE?

It doesn't.

I agree that implementing deep copy sounds straightforward, at first. So do you specify copying from one origin root to another destination root? Do you want inclusion or exclusion rules? How do you specify app bundle relative paths? Will you want macro expansion? Do you want to specify one-off resources from inside or outside the project to be copied to arbitrarily paths in the target bundle? Does it matter which parts of the hierarchy exist first, or are copied in which order? And for each path in a hierarchy do you implicitly or explicitly exclude or include them from the classpath?

Actually answering these questions takes time (writing them off the top of my head sure did), and implementing them takes even more time. And every tool that has to interact with bundles created from these specifications has to take them into consideration as well. Why not side-step these issues altogether?

For a 1.0 product, I think it's perfectly reasonable to draw a line in the sand as say "Yes, it seems easy, but not for 1.0. File enhancement requests, and we'll take the time to design something right, if it actually ends up being necessary for some real demonstrable reason."

>>>> 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.
> This part i do not understand.
> I'd imagine developer would use IDE to open project source, tweak and rebuild the bundle?

Not everyone who needs to make edits to an application should, or wants, to have the full source or all the dependent 3rd party libraries and deal with the full IDE experience.

Consider:
Localizers - insert loc-only jars into an app bundle without impacting the code jars
Designers - inserting artwork jars into an app to change appearance or branding
Deployment engineers - drop new resources into the bundle to change license checking
Testers - swapping in different code jars between builds to isolate regressions

The IDE isn't going to be the only tool driving this ant bundling task if you want to enable these workflows.

>> 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 IDE rely on external ant task to build the bundle i'd expect it will rely on external tools to update it. Why it is wrong process to assume?
> IMHO, it seem weird for IDE to depend on internals of bundle that is generated by tool IDE does not control.
> 
> IMHO, we are discussing utility to "package" what IDE built as platform bundle.
> It will be nice to support what IDE outputs as an input for this utility.

The IDE should (and in many situations has to) play well with a much larger ecosystem of tools, of which this bundler is one small (but hopefully very reusable) part. There is no reason why these bundles should not be cross edit-able between IDEs as well.

>>  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.
> What is "edit whole app" feature?
> What is use case for editing the app without changing sources? Why rebuilding the package is not sufficient?

See above.

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.



More information about the macosx-port-dev mailing list