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

[Daniel Zwolenski]

I have added more to the JNLP generation in
https://github.com/zonski/javafx-deploy-lib 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:
https://github.com/zonski/javafx-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 gmail.com> 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  (
> http://mojo.codehaus.org/osxappbundle-maven-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 bestsolution.at
> > wrote:
>
>>
>>
>> Von meinem iPhone gesendet
>>
>> Am 13.11.2012 um 00:27 schrieb Knut Arne Vedaa <
>> knut.arne.vedaa at broadpark.no>:
>>
>> > 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
>>
>
>