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

[Daniel Zwolenski]

Latest release of the Maven plugin has been pushed to central and includes
JNLP generation and JAR signing (see
https://github.com/zonski/javafx-maven-plugin).

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 (https://github.com/zonski/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
helpful?)

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 gmail.com> wrote:

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