Bundled app launcher changes

Greg Brown greg.x.brown at oracle.com
Wed Feb 1 05:45:45 PST 2012

> The "runtime" should only be specified if you are providing a full path to a different one.

The "runtime" property is optional. If you don't specify it, the launcher stub will look for a shared JRE. Otherwise, the runtime you specify will be copied into the app bundle.

> 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.

You can specify either a JRE or a JDK.

> 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?

I didn't think so. Java resources are generally pulled from the classpath - a Java app wouldn't usually be aware that it is running in a bundle so it wouldn't have a way to get to those resources.

> 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 chose "bundlejars" because the primary purpose of the task is to take a set of JARs and wrap them in an app bundle. I'm not opposed to the other suggestions, but I think "bundlejars" is appropriate. 

If we had to change, I think I'd prefer "bundleapp" to "createapp". The tool itself is currently called "JAR Bundler", so the task becomes "bundlejars". "bundleapp" implies that the tool should be named App Bundler, which is OK, but "createapp" -> App Creator doesn't seem appropriate.

> 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 agree. I have been thinking about that and wondering how we might support it. Any suggestions would be much appreciated.


More information about the macosx-port-dev mailing list