Bundled app launcher changes

[Greg Brown]

> What the expected output?
> Bundle as directory that is ready to go to dmg/pkg? or dmg itself?

The output is an application bundle in the specified output directory. It is not a disk image.

> Questions:
>   a) How one specify set of jars?

Use one or more nested <classpath> fileset elements.

>   b) What if application expects jars/resources to be in the multiple folders?

You can use multiple <classpath> elements.

>   c) How do i specify data or other resource files to be included?

Include them on your classpath (e.g. in your class directory or JAR files), as you would with any other Java application.

>   d) How do i add native libs?

It isn't shown in this example, but the task also supports a nested <nativeLibrary> element that you can use for this purpose.

>   e) Can i add custom frameworks, etc?

Not at present.

>   f) Why we refer to Java Runtime?
>         runtime="${env.JAVA_HOME}/../.."
>      IMHO, we could assume people install JDK and should point to JDK bundle root as root for cobundle.

In order to comply with Apple's licensing policy for app store redistribution, we need to support an embedded JRE. If you do not specify a JRE, the launcher will look for a locally-installed shared runtime.

>  g) Any way to specify minimum platform requirements (even dmg has it)?

Which platform? Java, OS X, or both? 

>      DMG also allows to include images, release notes, etc. And what folder to drag app into (by default Applications)
>      Obviously most of customization options could/should be optional elements but people like to tune these things.

I think DMG packaging is best left to a separate task (see below).

>  h) can i select subset of runtime? E.g. not include javafx, etc.
>       Perhaps java could be separate element?

Since you specify the runtime that is included, you can point it to any custom version you like.

> Do we have any docs explaining task parameters?

Not yet. But we should definitely have that before we release this.

> Overall, IMHO, it make sense to see if we can extend approach/syntax we use to bundle javafx apps.
>   http://docs.oracle.com/javafx/2.0/deployment/javafx_ant_task_reference.htm#CIACDJHC

I'm not sure what you are referring to specifically, but I didn't see anything that mentioned creating Mac app bundles for JavaFX apps. Actually, since JavaFX apps are ultimately just Java apps, I imagine that they will also be packaged using this task.

> Specifically i am thinking it will be useful to have
>   a) some kind of "resource" element that could include arbitrary set of filesets
>       And resources could be of different types (e.g. jars, native, frameworks, icon, "custom", etc)

Fundamentally, this is a tool for packaging Java apps, so I'm not sure what the value would be in supporting non-Java resources. All of your Java resources just need to be on your classpath.

>   b) application descriptor - most of what you have on bundledapp right now
>         (but not java runtime location, dest file, etc.)

Can you elaborate on this? I'm not sure what you mean.

>   c) some kind of target image abstraction
>         (icon and other dmg properties)

Also not quite sure what you mean here. Icon is already supported. It might be nice to support automatic DMG packaging, but to me that seems like it would be best implemented as a separate Ant task that could be called by your build script after <bundleapp>.

G