JavaFX Maven Plugin
zonski at gmail.com
Wed Nov 14 05:09:30 PST 2012
Not sure if you came into the group before or after some of the more recent
discussions. Probably worth having a flick through the recent archives on
the topic of "JavaFX Packaging tools".
As discussed somewhat before, the use of reflection was a work around the
licencing issues. I'm legally not allowed to put the jar in a public Maven
repo so instead I hacked up a solution that looked for the JAR in the JDK
and used reflection to call onto it. Crude, but after a year of trying to
get better Maven support going in JFX, this was my fallback.
There's many ways to skin a cat, and your option is perfectly valid too -
basically doing the same search into the JDK but instead of using
reflection, installing it into the local repo (and thus avoiding licencing
issues, assuming it's a private repo). One small drawback to this for me is
that the developer still has to add dependencies to their POM, and as soon
as Java 8 (or possibly 7u10) properly add JFX to the classpath those
dependencies will need to be removed. In the hack I went for, the mess is
hidden from the developer and the pain is all hidden inside my code -
easier for the user, harder for me.
In any case, I've started on a different tact to the reflection based one
anyway. The more I've tried to use the built in JFX tasks, the more
limiting I've found them. So now I'm in the process of writing an
alternative toolset (https://github.com/zonski/javafx-deploy-lib). At this
stage I'm just creating my own JNLP and Applet generators, but if it makes
sense and I have the energy I may look at going all the way. Once the JFX
tools are open sourced I don't believe there's anything stopping me from
taking bits that I like directly out of there if I use the same licence
(need to check up on this). So stuff like the signing I might take verbatim
but stuff like the JNLP generation, I'll completely replace with something
Depending on motivation and time, I may also look at doing the native
bundling in a different way and also adding Windows 8 Metro support. I'd
really like to avoid developers having to download additional tools like
WiX for standard builds. This could be a huge amount of work though, so
need to look into it before aiming too high (and alternative might be to
look at the Maven plugin downloading WiX magically).
I've also shot off some questions to the guys building the compact JRE
profiles and in theory there is nothing stopping us from getting these
working for desktop as well. If we can make that happen then building in
compact profile management into the build tool would be another great goal
(and maybe even one day being able to build all the cross-platform
installers on the one OS - pipe dream). All of this work would also be a
necessary pre-cursor to mobile, which I'm still naively holding out hope
that this will one day get sorted. A Maven plugin where you just add an
extra <android> and <ios> tag into it and magically get a distro ready for
the app stores would be very nice.
If you, or anyone, are interested in working collaboratively on this, I'd
be keen for that. My goal is to have a super slick Maven tool that can
build production-grade, release-ready JavaFX apps with absolute minimal
fuss. If that same code can then be shared between Gradle and other build
tools giving developers the full spectrum of choice that would be a good
thing in my book. I feel like the deploy-lib is the way to go, rather than
wrappering the JFX tools so if you're on board with that basic direction,
then join on in.
On Wed, Nov 14, 2012 at 9:23 PM, Paul Merlin <paul at nosphere.org> wrote:
> I had to use JavaFX and Maven in a university course and for a company
> project lately but the current plugin do not support maven enough for my
> needs so I wrote another javafx plugin that don't rely on reflection and
> has more maven features.
> Currently it does the following:
> - support many configurations properties
> - allow execution of JavaFX applications using exec-maven-plugin
> - package and attach JNLP/Applet distributions
> - package and attach images distributions
> - package and attach installers distributions
> As produced distributions are attached to the build the plugin can be used
> to roll releases using the maven mechanisms.
> All this was easier because it's not using reflection. The drawback here
> is that my plugin force you to add dependencies to javafx artifacts to your
> The README explain how to use the plugin.
> Daniel is aware of my work on this and we certainly will combine our
> efforts at some point (this should occur when the build tools are
> opensourced). For now developpers have the choice between the two
> BTW I have one question. JavaFX will be included in JavaSE classpath at
> some point (7uX, 8?). People building against Java versions published
> before this change will still have to explicitely depend on JavaFX to build
> their applications, don't they?
More information about the openjfx-dev