Bundled app launcher changes

[Igor Nekrestyanov]

Thanks, this was very useful clarification.
>>>> 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.
Sure, i totally agree on this.
And having standard tools to deploy apps is very helpful.
> 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.
 > This is only a concern for legacy apps.

These are statements i do not agree with.

It is not just NB and project build by NB.
IMHO, it is pretty natural for complex app to have complex structure 
(not complex way to launch, but they use a lot of resources in runtime).
E.g. I just checked IntelliJ IDEA and its Mac bundle also has tons of 
files on multiple levels.

 > "introduce complexity into how this app bundler tool"

IMHO, ant FileSets and copy tasks have everything needed to handle deep 
file structures.
Reusing this functionality will be easy.

IMHO, for tool to be useful it needs to have backward compatible API.
Therefore it is critical to make it flexible and extendable to be able 
to easily add new features in the future and yet preserve compatibility.
It takes time for external IDE developers to start using these tools and 
if next version will be changed in the incompatible way it will break users
trying to upgrade JDK bundle.

> 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. 
Well, i think it is easier than you may think.
Ant has it. Just allow developers to use standard fileset and 
resourcesets to define bundle content.

This is partially what i was trying to explain - proposed any task look 
like reinventing the wheel.
It does solve new problem (producing the bundle) but it does not follow 
usual ant approach to produce other type of "bundles"
(e.g. jar, zip, copy, etc.). IMHO, right way to implement it would be to 
extend and customize existing tasks.

> And every tool that has to interact with bundles created from these 
> specifications has to take them into consideration as well. 
I do not see the issue here.

If someone rely on specific workflow - e.g. ability to inject new 
localized jar into bundle there should be policy where these apps are 
expected to go.
If tool used to produce and inject these jars imply they need to be in 
specific folder or at top level then application need to be packaged in 
the compatible way.

I do not see why it has to be enforced by the bundle tool and no other 
options should be allowed.

> 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." 
IMHO, the reason is ability to create 2.0 or even 1.1 that will be 
backward compatible.

>>>>> 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.
Absolutely, it would be good to (eventually) provide ant tasks to 
support these scenarios if there will be demand for it.

And if it is desirable to use IDE to update the bundle for these 
scenarios then IDE can use these additional ant tasks for it.

To me ant tasks serve as abstraction layer that hides internal structure 
of the Mac bundle from the IDE.

-igor