Bundled app launcher changes

[Mike Swingler]

On Feb 10, 2012, at 6:16 PM, Scott Palmer wrote:

> On 2012-02-10, at 8:47 PM, Mike Swingler wrote:
> 
>> On Feb 10, 2012, at 5:16 PM, Michael Hall wrote:
>> 
>>> On Feb 10, 2012, at 7:01 PM, Igor Nekrestyanov wrote:
>>> 
>>>> 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?
>>> 
>>> I would sort of like to be clear on how classpath will work with the launcher and Info.plist.
>>> Previously classpath was specified in the plist itself.
>>> e.g.
>>> 		<key>ClassPath</key>
>>> 		<array>
>>> 			<string>$JAVAROOT/halfpipe.jar</string>
>>> 
>>> As I am understanding how things will be now. 
>>> The ant task will copy fileset entries into fixed locations within the bundle that will be the runtime classpath.
>>> whatever.app/Contents/Java/Class/*.class
>>> whatever.app/Contents/Java/*.jar
>>> 
>>> would be my guess as to where the ant task will place things.
>>> is this how classpath will work?
>> 
>> Perhaps the tag name <classpath> is subject to too much misinterpretation. Would <resource classpath=true> make it clear that it's a resource that should be copied into (whatever.app)/Contents/Java/, and may or may not be put on the apps classpath in the Info.plist?
>> 
>> If the classpath=true attribute is set, then a $JAVAROOT/myStuff.jar entry will be appended into the apps runtime classpath VM argument.
>> 
>> Would that syntax be more clear?
> 
> Why re-invent?  The standard Java mechanism is to provide the class path in the main jar's manifest.  Existing Ant tasks will already handle that. Why is anything more than pointing to the main jar needed?  The manifest in the main jar can be used to figure out what resources to bundle and the relative locations they need to be placed in.  While raw .class files in folders could be referenced, it is highly unusual for an application to be distributed that way.

This means you'd have to intertwine process of creating a Manifest with the end deployment filesystem structure. This seems rational, however it does make adding/removing other classpath entries harder without reopening/repacking the main jar.

Is this actually a common deployment practice? I'm no fan of duplicating classpath information, but I think there are often situations where you bring in different libraries based on the deployment platform (things like Quaqua come to mind).

Regards,
Mike Swingler
Apple Inc.