Bundled app launcher changes

Igor Nekrestyanov igor.nekrestyanov at oracle.com
Fri Feb 10 23:15:34 PST 2012


>>> If all elements of the fileset were to be copied to the $JAVAROOT 
>>> flat (and performing a straight copy of directories), how would you 
>>> specify which individual files or fileset groups should be included 
>>> on the classpath?
>> In fact, you do not need this.
>>
>> Java has support for classpath in the manifest. we should expect that 
>> whatever we bundle can start as
>>     "java -jar main.jar"
>> I.e. expect executable jar file with classpath in the manifest.
>>
>> This is what any Java IDE or packaging tool (ant, maven, etc.) can 
>> produce easily.
>
> I would like to hear others opinion about using the Manifest as the 
> authoritative source for the classpath.
>
> AFAIK, there isn't any code in the native launching stub today that 
> will pick apart any of the jars to dig around and parse out the 
> Manifest. Perhaps there is a way to make use of the JLI_* helper 
> functions? This also raises another point - how do you specify which 
> .jar is the "primary" out of a file set? Simply specifying the main 
> class won't work - so then, should you be able to specify a (perhaps 
> Mac-specific) main class, and still read the classpath information 
> from the Manifest?
IMHO, you do not need to dig for manifest.
If we expect Class-Path and main class to be in the manifest then in the 
native launcher you only need to pass
    a) jvm options (if any)
    b) jar path/to/main.jar
to JVM and it will start the app.
No need to set classpath or native lib path.

I'll paste my initial sample below again to answer your other questions.

Specifically here is how <application> can be defined:

<application main="SwingSet2.jar">
        <argument value="foo=bar"/>
</application>

i.e. no need to specify main class, etc.

>  I'm not convinced that the Manifest is a good place to define the classpath, since it cannot be (easily) augmented per-platform ...

BTW, manifest task in ant is quite powerful these days.
I believe it can merge existing classpath with classpath in manifest you are adding to jar.
See
    http://ant.apache.org/manual/Tasks/manifest.html

And ant jar task also has some merge support for class path manifests,

-igor

Tentative sample usage (a lot of elements are optional, see simplified sample below):

>    <bundleapp outputdirectory="." name="SwingSet2">
>
>       <!-- Application properties. This is effectively plist. May be wise to support reference to predefined plist in the file -->
>       <properties
>         displayname="SwingSet 2"
>         identifier="com.oracle.javax.swing.SwingSet2"
>         shortversion="1.0"
>         >
>
>         <!-- custom plist property, see "/usr/libexec/PlistBuddy -h" -->
>         <property name=":SUFeedURL" value="http://somewhere/sparkle-appcast.xml"/>
>         <property name=":CFBundleDocumentTypes:2:CFBundleTypeExtensions" value="aaa"/>
>       </properties>
>
>        <javaruntime sdk="path/to/jdk.bundle">
>         <option value="-Xms32M"/>
>         <option value="-Xmx256M"/>
>         <option value="-Dapple.laf.useScreenMenuBar=true"/>
>       </javaruntime>
>
>       <!-- Expect that SwingSet2.jar has classpath element pointing to other dependent jars -->
>       <application main="SwingSet2.jar">
>         <argument value="foo=bar"/>
>       </application>
>
>       <resources>   <!-- default type are "app" resources -->
>          <!-- includes both jar and native libs -->
>          <!-- e.g. we could have SwingSet.jar, lib/one.jar, lib/two.jar, docs/README.html, lib/macosx/something-native.dylib -->
>          <fileset basedir="${dist.dir}" includes="**"/>
>       </resources>
>       <resources type="framework">
>          <fileset basedir="Sparkle.src" includes="**"/>
>       </resources>
>       <resource type="icon">   <!-- if present then copied and used as bundle icon -->
>          <fileset .../>
>       </resource>
>
>    </bundleapp>
Minimal deployment:
> <bundleapp outputdirectory="." name="SwingSet2">
> <!-- default properties can be derived from the bundle name.
>            version is 1.0 -->
>
> <!-- By default cobundle runtime used by ant -->
>
> <!-- Expect that SwingSet2.jar has classpath element pointing to other 
> dependent jars -->
> <application main="SwingSet2.jar">
> <argument value="foo=bar"/>
> </application>
>
> <!-- convinience way to sepcify single fileset that includes all files 
> -->
> <resources basedir="${dist.dir}"/>
> </bundleapp> 






More information about the macosx-port-dev mailing list