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

[Daniel Zwolenski]

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