Bundled app launcher changes

[Mike Swingler]

On Jan 30, 2012, at 9:30 AM, Scott Kovatch wrote:

> Hello,
> 
> Greg Brown has been busy working on an Ant task for creating a Mac .app bundle. As a preview, here's an example of it in use:
> 
>       <bundlejars destDir="."
>           name="SwingSet2"
>           displayname="SwingSet 2"
>           identifier="com.oracle.javax.swing.SwingSet2"
>           icon="JavaAppLauncher/resources/GenericApp.icns"
>           shortversion="1.0"
>           runtime="${env.JAVA_HOME}/../.."

The "runtime" should only be specified if you are providing a full path to a different one. Also, there should be a way to specify if you only want to bundle the JRE, or if you need a full JDK. This will change the output tag in the Info.plist, and will change what is copied from what location.

>           mainclass="SwingSet2">
>           <jarfile path="/Library/Java/Demos/JFC/SwingSet2/SwingSet2.jar"/>
>           <argument value="-Xms32M"/>
>           <argument value="-Xmx256M"/>
>           <property name="apple.laf.useScreenMenuBar" value="true"/>
>       </bundlejars>

There should be a way to add a number of jars to the classpath, which will implicitly get copied into (bundle)/Contents/Java. Is that just by adding more <jarfile/> tags? Should there be an affordance for specifying non-jar/non-classpath resources that should also get copied into (bundle)/Contents/Java? It may make sense to provide a <resource/> tag for art or other Mac-specific resources to be copied into (bundle).app/Contents/Resources. Or perhaps just a <copy/> tag that takes a source and a destination.

I'm also not wild about the tag name <bundlejars/>. That may be ambiguous with some sort of jar coalescing. Perhaps <createapp/>, or <bundleapp/>. Any other suggestions?

I know you can't support this on non-Mac builders, but you should definitely plan to provide a codesigncert= argument which will sign the primary stub executable with a provided certificate. This will be Very Important to some developers.

> I'm wondering where this should be checked in, though. Building an application bundle from JARs, resources, and launcher stub is really a deployment task as opposed to a pure JDK feature, but Web Start and the plugin are not open sourced so I don't see a public 'deploy' project happening in the near future. We definitely want to push this out so people can start building applications with the Mac JDK. Anyone have an opinion on that?

Currently, the bundling/stub building stuff is in jdk/src/macosx/bundle in the source. That seems as good of a place as any at the moment.

As far as where the physical artifacts go, I think (bundle).jdk/Contents/Home/lib/ makes sense, since other JDK tools like jconsole, tools.jar, and the .idl files live there.

> Also, we are working on an simpler version of the launcher code that will reuse more of the generic/command-line launcher code in jdk/src/share/bin/java.c. Kumar Srinivasan checked in a refactoring of the command-line tools so that all of the runloop management, argument parsing, and other setup is now done in JLI_Launch. That means we can rip out the code that duplicates that work in the app launcher and call through to JLI_Launch instead.  I started on this and handed it off to Greg. We should have something to share in the next week or so.

Cool. I always wanted to take a hatchet to JLI_Launch(), but I'm glad someone else is on the hook for making sure it doesn't break on all the other platforms. :-)

Regards,
Mike Swingler
Apple Inc.