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

Daniel Zwolenski zonski at gmail.com
Wed Nov 14 04:44:49 PST 2012

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

More information about the openjfx-dev mailing list