Bundled app launcher changes

[Greg Brown]

> If it is like regular fileset then why do we need new element and not reusing fileset?

The classpath element is implemented using FileSets. We just don't call the element <fileset>, since that would be ambiguous.

>>> Also, with this approach the app running in the dev environment will be different from app running from the bundle.
>>> E.g. you have to set classpath again.
>> Yes. But this is no different from the existing JarBundler tool provided with OS X or the open-source JarBundler Ant task that serves a similar purpose:
>> 
>> http://informagen.com/JarBundler/
> ok good to know.
> but why do we think it is best/ideal way?

I explained this at the end of my previous email. The current design is intended to parallel the invocation model used by the java command.

> Do we try to stay compatible with that tool?

No.

>>> Can you elaborate a bit why do we want to set classpath at the package time?
>> Because we need to know which JARs/class files need to be added to the app bundle.
> Ant has plenty of existing mechanism to define resource sets.
> Why we need new one? Why it needs to be "ordered" list?

We didn't define a new one. We're using a standard Ant FileSet.

>>> My understanding is that JRE to cobundle will always be in the
>>>   jdk.bundle/MacOS/Contents/Home/jre
>> I'm not sure that is a reasonable assumption. Why not allow the developer to choose?
> As far as i understand
>   a) ant task we are discussing will come with jdk bundle

Not necessarily. That would certainly be convenient, but we don't know for sure yet how it will be deployed.

>   b) jdk bundle is the only planned way to distribute openjdk on Mac

Correct.

>   c) there will be no official JRE bundle on Mac

Not true. The user may have installed the Java plugin, which will provide a shared JRE.

To the rest of your comments/questions - the changes you propose are largely stylistic and would require an extensive rewrite of the Ant task. IMO, that simply isn't justified. The current design is sufficient to address the majority of the use cases we're targeting with the task, and it is consistent with the approach taken by the earlier tools (e.g. JarBundler). Further, it can be easily extended to accommodate some of the other things you have mentioned (e.g. min version and plugins), either before it is released or in a later update.

Thanks for your feedback.

G