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

[Claus Luethje]

I'm very interested in having Maven support for JavaFX. Having options to use templates will come in handy, I'm sure.
We're not ready yet with our project to see if standard tooling is enough.

As building and deploying is central for any application, I think this topic belongs on this list.

Just my 0.02 ct

Claus



Am 13.11.2012 um 02:03 schrieb "Daniel Zwolenski" <zonski at gmail.com>:

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