Bundled app launcher changes

[Igor Nekrestyanov]

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

Questions:
    a) How one specify set of jars?
    b) What if application expects jars/resources to be in the multiple 
folders?
    c) How do i specify data or other resource files to be included?
    d) How do i add native libs?
    e) Can i add custom frameworks, etc?
    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.
       Ant task need to be aware of how to find files in the bundle.
       This will simplify life of IDEs such as NB as they only keep 
track of where current SDK is located.
   g) Any way to specify minimum platform requirements (even dmg has it)?
       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.
   h) can i select subset of runtime? E.g. not include javafx, etc.
        Perhaps java could be separate element?

Do we have any docs explaining task parameters?

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

We do not support dmg bundles there (yet) but we clear want to and 
javafx will be part of java platform soon.
It would be nice to have these to play nice together from the beginning.

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)

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

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

What do you think?

-igor

On 2/10/12 4:25 AM, Greg Brown wrote:
> Hi all,
>
> Here's an updated version of the sample Ant task Scott sent earlier. The task has been renamed to "bundleapp" rather than "bundlejars", and the<jarfile>  element has been replaced with<classpath>, which is now a file set that can point to either class directories or JAR files:
>
>      <bundleapp outputdirectory="."
>          name="SwingSet2"
>          displayname="SwingSet 2"
>          identifier="com.oracle.javax.swing.SwingSet2"
>          shortversion="1.0"
>          runtime="${env.JAVA_HOME}/../.."
>          mainclassname="SwingSet2">
>          <classpath file="/Library/Java/Demos/JFC/SwingSet2/SwingSet2.jar"/>
>          <option value="-Xms32M"/>
>          <option value="-Xmx256M"/>
>          <option value="-Dapple.laf.useScreenMenuBar=true"/>
>          <argument value="foo=bar"/>
>      </bundleapp>
>
> Other changes include:
> - "destDir" attribute renamed "outputdirectory"
> - "mainclass" attribute renamed "mainclassname"
> -<property>  element renamed<option>; now specified using single "value" attribute rather than "name" and "value"
>
> Finally, the launcher stub has been updated as outlined below to use JLI_Launch().
>
> Questions and comments are welcome.
>
> Greg
>
> On Jan 30, 2012, at 12:30 PM, 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}/../.."
>>            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>
>>
>> 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?
>>
>> 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.
>>
>> -- Scott K.
>>
>> ----------------------------------------
>> Scott Kovatch
>> scott.kovatch at oracle.com
>> Santa Clara/Pleasanton, CA
>>
>>