Bundled app launcher changes

[Igor Nekrestyanov]

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??
>
> 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.


>> 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 ...
>>> 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.

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?


>
>>> 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?

> 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.

>   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?

-igor
>
> 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.
>