Bundled app launcher changes (original) (raw)

Igor Nekrestyanov igor.nekrestyanov at oracle.com
Fri Feb 10 10:25:40 PST 2012

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 element has been replaced with, 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.JAVAHOME}/../.."_ _mainclassname="SwingSet2"> Other changes include: - "destDir" attribute renamed "outputdirectory" - "mainclass" attribute renamed "mainclassname" - element renamed Finally, the launcher stub has been updated as outlined below to use JLILaunch(). 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.JAVAHOME}/../.."_ _mainclass="SwingSet2"> 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 JLILaunch. That means we can rip out the code that duplicates that work in the app launcher and call through to JLILaunch 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

More information about the macosx-port-dev mailing list