Bundled app launcher changes

[Igor Nekrestyanov]

On 2/10/12 11:16 AM, Greg Brown wrote:
>> 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.
ok.
separating dmg creation make sense.

But bundle Info.plist and this can be heavily customized. Make sense to 
support that (e.g. like jar task supports customizing manifest)
>> 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.
Would you mind to give an example of this?
E.g. NB typically generate something like
    dist/app.jar
    dist/lib/dep-lib1.jar
    dist/lib/dep-lib2.jar
    ...

And manifest in the app.jar is set to find other jars in the lib folder.

How do i package it to preserve structure?
>>    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.
Do you mean i can include folder to the classpath and then all 
subdirectories will be copied over to the bundle?

I am not sure how this classpath element work.
In your example you are using absolute path - do you mean user will not 
be able to install same app to other location (e.g. to Library in the 
home dir?)?

>    <classpath file="/Library/Java/Demos/JFC/SwingSet2/SwingSet2.jar"/>

It seems a bit strange to me if applications are not relocatable.

Also, with this approach the app running in the dev environment will be 
different from app running from the bundle.
E.g. you have to set classpath again.

Can you elaborate a bit why do we want to set classpath at the package time?
IMHO, better way it to expect application is runnable as
    java -jar app.jar
before we package it as Mac bundle.
And packaging process simply copy over set of jars/resources keeping 
their relative structure.

>
>>    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.
Any other examples to look at?
>>    e) Can i add custom frameworks, etc?
> Not at present.
IMHO, thinks like Sparkle, etc. are relatively popular.
Would be good to support them.
>
>>    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.
I understand why we cobundle JRE. I do not understand why we expect 
developer to provide reference to it in this way.

My understanding is that JRE to cobundle will always be in the
    jdk.bundle/MacOS/Contents/Home/jre

Based on your example it seem that developer need to point to 
"jdk.bundle/MacOS/Contents/Home" and this exposes internals of jdk bundle.
I am suggesting to point to sdk instead of runtime like
      sdk="jdk.bundle"
If sdk is not specified then use sdk used to run this ant task.

>>   g) Any way to specify minimum platform requirements (even dmg has it)?
> Which platform? Java, OS X, or both?
OS X version.
E.g. need 10.7.3, etc.

java is cobundled => version is controlled, no need in yet another 
mechanism.
>
>> 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.
yes, it does not create Mac bundles.
> Actually, since JavaFX apps are ultimately just Java apps, I imagine that they will also be packaged using this task.
Absolutely, i agree this is right way.

What i am trying to refer to is that with JavaFX we proposed "packaging" 
guidance for the java app developers.
It is part of JavaFX runtime but
>
>> 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.
I do not follow here.

Java applications do not need to load resources from classpath.
E.g. Netbeans is the java application - see how many "other" resources 
they have in the application bundle.
One other typical example - your app need to feed these resources to 
other tools, they can not be in jars.
E.g. open html docs using web browser, etc.

Assuming everything is on classpath is not realistic, IMHO.
>>    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.
Ok, here is tentative example

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

Most of elements above are optional. Minimal set could be along these lines:

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

-igor