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

[Daniel Zwolenski]

Thanks for the tip Werner but the Maven post you referenced is using a work
around by calling the ANT tasks from within Maven (roughly on par with
calling a Make file from within ANT - i.e. a last resort). The Maven plugin
I have built is intended to completely replace these sorts of work arounds
so it won't need that trick you outlined. Hopefully no one should ever have
to worry about resource stuff like that in Maven land.

For anyone who is interested I moved my early/work-in-progress code for
generating a JNLP from a velocity template to a separate GitHub project:

    https://github.com/zonski/javafx-deploy-lib

At this stage it just generates a simple JNLP file based on a default
template or a custom one and parameters that you pass in. There are no
Maven dependencies or anything Maven specific to it.

The idea being that this could be reused in Gradle, SBT, or even ANT if
anyone wants to do that. I will be growing this over the next week or so
and then making my Maven plugin call onto this (deriving the settings from
the POM). Let me know if anyone is interested in working on this, as the
level of doco, etc, that I go for will depend on whether it's just me using
it or others as well. Obviously if anyone wants to chip in and contribute
we'll all make a lot faster progress working on this common module together.

If you've worked out how the packaging code works then you should have no
trouble working out what's going on in this one too. Basically this is a
direct alternative to calling onto the built-in JFX tools. I plan to extend
this to generate HTML for webstart and applets - so the JFX tools will be
totally bypassed in Maven land for Applets and JNLP.

The more I dig into the official packaging tools the more I'm thinking it
would be better just to recreate them as a true open source project without
all the weird stuff and ant-focused design, not to mention Oracle red tape
and very slow release cycle. JNLP and Applet are easily rebuilt, JAR
shouldn't be much of an issue. Native would be a bigger job but that stuff
really could do with a ground-up rebuild to make it clean, modular and
customisable anyway. Maybe I'll get to this, maybe I won't.

In these early stages I reserve the right to completely change the code
that's in there as I work out what I need. I'll start putting up snapshot
builds soon and only once its stable enough release it into the central
repo.

I went for the GPL licence so that it can be used in the same boat as the
OpenJDK stuff but I don't really care. If anyone wants/needs an alternate
licence, let me know.







On Tue, Nov 13, 2012 at 10:08 PM, Werner Lehmann <
lehmann at media-interactive.de> wrote:

> Hi,
>
> let me hijack this thread to share a little detail I learned about the
> <fx:jar> task the other day. For the manifest I needed to reference
> dependency jars from several different directories. Those jars are also
> used for compilation so I have an Ant resource collection for those already:
>
>     <union id="myjars">
>       <filelist dir="${core.lib}">
>         <file name="activation-1.1.jar"/>
>         ...
>       </filelist>
>       <filelist dir="${guicore.lib}">
>         ...
>       </filelist>
>       ...
>     </union>
>
> Using Ant's pathconvert I can convert this into a string suitable for the
> manifest class-path attribute. Now, with <fx:jar> the documentation
> indicates that I should use <fx:resources> to list jars needed for the
> class-path (or, JavaFX-Class-Path is what it actually generates).
>
> Unfortunately, <fx:resources> is not compatible with Ant's resources, and
> it cannot reference them, let alone offer the flexibility of pathconvert,
> e.g. to prefix each jar in the path. So my nice and existing and lengthy
> resource collection did not work and I'd have to repeat all that for
> <fx:resources>.
>
> This is a problem for Maven as well, it seems:
>
>> http://myjavafx.blogspot.de/**2012/08/building-signing-and-**
>> deploying-your.html<http://myjavafx.blogspot.de/2012/08/building-signing-and-deploying-your.html>
>>
>
> This blog post showed that you can simply ignore <fx:resources> and
> continue to provide the class-path yourself. It wouldn't have occurred to
> me :)
>
> So I can still do this:
>
>     <fx:jar destfile="...">
>       <fx:application name="..." mainClass="..."/>
>       <fileset dir="..."/>
>       <manifest>
>         <attribute name="Built-By" value="..."/>
>         <attribute name="JavaFX-Class-Path" value="my.dist-classpath}"/>
>       </manifest>
>     </fx:jar>
>
> Whereas my.dist-classpath is provided by pathconvert (with a
> chainedmapper, flattenmapper, globmapper) and generated from myjars.
>
> Might be useful for somebody.
>
> Rgds
> Werner
>
>