JavaFX packaging tools (was Re: JavaFX plugin for SBT)

Daniel Zwolenski zonski at
Sun Nov 18 05:26:09 PST 2012

Latest release of the Maven plugin has been pushed to central and includes
JNLP generation and JAR signing (see

JAR signing is a straight call out to the JFX packaging tool. JNLP/HTML
generation completely bypasses the JFX packaging tools and instead uses the
code in the javafx-deploy-lib (,
which uses Velocity templates to generate the files.

We didn't really get any conclusions on default directories and file names
for things like jnlp templates, keystores, icons, splash screens so I have
picked some (mostly putting things under 'src/main/deploy'). Refer to the
online doc for more information.

Also I am currently putting the executable JAR file back directly into the
'target' directory with a -jfx suffix. The 'webstart' bundle is in it's own
directory under target/webstart and includes a copy of the JAR, the JNLP
file, the HTML file, and any icons, images, etc. Native bundles go under
'target/bundles' but this is mostly because the JFX tools don't allow me to
customise this much more than this. I think I like Danno's suggestion of
putting the distros directly under target (except webstart and applet which
are special because they have multiple files in the bundle - I would be
open to zipping them up into the target directory if we thought that was

It's still early enough to change these if people give a good alternative
but a few more releases and I will be reluctant to change anything without
strong reason to. Now's a good time to shout out if you have an opinion.

On Wed, Nov 14, 2012 at 11:44 PM, Daniel Zwolenski <zonski at> wrote:

> I have added more to the JNLP generation in
> It now uses Velocity to
> generate both a JNLP and a HTML file (linking to the JNLP) from settings
> passed into it.
> I have also done some work in integrating this into my Maven plugin:
> This work is all checked in and working in a rough form. I've not yet
> pushed it into any Maven repo though so at this stage you have to get the
> source out to do anything with it (I'll try to get at least snapshots up
> over the weekend).
> If you want to generate a webstart bundle, just add <webstart/> to your
> POM's plugin configuration. You can add settings if you want, but in
> general it will take info from the POM (such as name, vendor, organisation,
> etc). The jnlp and html files will be generated in "target/webstart"
> The generated JNLP and HTML look ok but the resulting app won't actually
> launch yet as they are missing some of the magic attributes now required by
> JFX. This is really just a case of updating the default template file to
> look like what comes out of the JFX packaging tools. Should be easy,
> hopefully over the weekend. Signing the jar is a separate problem though,
> probably won't sort that out this weekend.
> I like this templating approach a lot better than the JFX tools. With the
> JFX ones you get what comes out and don't get any real say in this. In this
> code you can provide a custom velocity template for both the JNLP and the
> HTML and you can completely design it how you want (and you have available
> to you all the settings/parameters used to generate the JNLP). Rolling the
> same strategy out for Applets should be easy, and down the track adding a
> template-based HTML file that helps users download the appropriate native
> installer for their system might also be a nice thing to have.
> In response to Knut, it's the static nature of the output of the JFX tools
> that I find limiting. This templating is one example, but also control over
> a lot of things like output directories, even fine grained security
> settings, etc is not currently supported by the JFX tools. The tools could
> obviously be extended to support them, but there are several limitations to
> this (e.g. can we use a third party library such as velocity?). My biggest
> worry though would be the very slow release cycle to the tools - as soon as
> it is open sourced we will be able to fix up a lot of the obvious holes but
> it could be months (or years) before these fixes make it into an official
> release. What's more we can never guarantee which version of the tools the
> user will have (are they using JDK1.7 or JDK1.8, etc?) so we cannot link to
> specific features. Having a separate open source project with stand alone
> build tools works better for me.
> Feel free to use them if you want, but calling straight onto the ant files
> is definitely a fine and simple option if that's what you prefer.
> On Tue, Nov 13, 2012 at 12:01 PM, Daniel Zwolenski <zonski at>wrote:
>> > Is this thread relevant for the open-jfx list, or should we move it to
>> private email?
>> Seems relevant to me given that a lot of this relates back to the
>> structure of the official JFX packaging tools, how they will be used and
>> what features they should have built in. If anyone has any objections
>> though, let us know and we'll take it off list.
>> > What I do in the SBT plugin is that I generate a build.xml file that
>> contains <fx:jar> and <fx:deploy> task definitions, and pass on
>> plugin-defined settings from the project's .sbt build file to these tasks,
>> then run Ant on it.
>> The Maven plugin calls directly onto the packaging tool code (which the
>> ANT tasks call onto internally), cutting out the ANT middle man.
>> > There also needs to be a "use this file" support.  Auto-generation is
>> nice but sometimes there are random things that have to be put in
>> for random reasons that the conventions don't support.
>> That's what I was meaning by "JNLP templating". My current thinking is to
>> use Velocity to generate the JNLP template and pass in known replacement
>> variables. If a custom template exists in the project (e.g. in
>> src/main/webstart/jnlp-template.vm) then it will automagically use this. If
>> none is supplied then it uses a built-in default one to produce a standard
>> jnlp file.
>> I'm intending to do something similar for generating a HTML file for
>> Applet deployment, and also a HTML file to launch the JNLP. The idea being
>> that the developer can just upload the HTML, JAR and JNLP to a server and
>> it is ready for action.
>> I wrote the first half of this code last night - hopefully will have it
>> working sometime next week. Currently I am completely bypassing the JFX
>> tool for JNLP and Applets as it is too limited.
>> My first question is whether anyone else is interested in doing the same
>> templating stuff in their build tools or whether you want to stick to just
>> wrappering the more limited functionality of the JFX packaging tools?
>> If no one else is interested, I'll just bundle this in my plugin code. If
>> others want to do the same thing then I can section off this code as a
>> Maven independent GitHub project or we could look at whether it's possible
>> to move it into the base JFX tools (not sure that's such a great idea
>> though).
>> > The ant task sniffs for package/<platform> in the classpath, so that is
>> why I did id that way.
>> Makes sense as a starting point. I'm hoping once we get the open source
>> code we will be able to change the defaults a bit and make it more
>> configurable. I'd rather us come up with good standards and change the
>> tools to meet, rather than just doing what the ant tools do as I don't
>> think they were built with cross-tool standards in mind.
>> On a side note, I'd definitely like the 'bundle' part of the code to be
>> more flexible so that we can turn on and off specific native installers via
>> params passed in. i.e. I'd like to be able to explicitly call the method to
>> build the MSI or the EXE not have to pass in a parameter of "ALL" or
>> "IMAGE" which could mean anything on any platform, etc.
>> > I don't like target/javafx.
>> Fair call, I'm not especially wed to it
>> > For example, the Maven DMG plugin  (
>> uses src/main/app-resources for soruce data and drops the DMG directly into
>> target/
>> I like the simplicity of putting the natives directly in the target
>> directory. We'd need a naming scheme though to differentiate between x86
>> and x64 MSI for example. Easy enough.
>> With JNLP and Applet though the bundles are not a single file, it's HTML
>> plus JNLP plus JAR (at a minimum). Does it make sense to bundle these
>> straight in target? or a zip for applet another zip for webstart (or a
>> combined zip with both)? or do sub directories make sense for these?
>> In Maven land I might also have to think about what to do with JNLP and
>> Applet if the packaging type is 'war' file. I might need to think about
>> that one a bit more.
>> > Much of this could be a matter of taste though.
>> Definitely. Would be good if we can standardise it but if our tastes
>> differ too much well then probably not worth going round in circles about
>> it too much and just do what we think best. Keen to work out what the
>> preferences are at least, and so far this has been a useful conversation
>> for me.
>> On Tue, Nov 13, 2012 at 10:46 AM, Tom Schindl <
>> tom.schindl at> wrote:
>>> Von meinem iPhone gesendet
>>> Am 13.11.2012 um 00:27 schrieb Knut Arne Vedaa <
>>> knut.arne.vedaa at>:
>>> > What I do in the SBT plugin is that I generate a build.xml file that
>>> contains <fx:jar> and <fx:deploy> task definitions, and pass on
>>> plugin-defined settings from the project's .sbt build file to these tasks,
>>> then run Ant on it.
>>> This is the way e(fx)clipse works as well and it works without problems.
>>> Beside that we allow people to configure the generation in an extra
>>> XML-File.
>>> Tom

More information about the openjfx-dev mailing list