Bundled app launcher changes

Igor Nekrestyanov igor.nekrestyanov at oracle.com
Fri Feb 10 17:01:10 PST 2012

On 2/10/12 4:55 PM, Greg Brown wrote:
>> 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.
But what is the new semantics in the "classpath" element?

>>>> 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
Why do we want to model anything but "java -jar ..."?
>>>> 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.
I do not follow here.
This is new tag name => new XML element:

<classpath file="/Library/Java/Demos/JFC/SwingSet2/SwingSet2.jar"/>

What i am missing?
>>    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.
No, it will not.
Current vision is that there will be no shared JRE on Mac.

> 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

More information about the macosx-port-dev mailing list