JavaFX Maven Plugin

[Paul Merlin]

Dan,

Daniel Zwolenski a écrit :
> Hi Paul,
>
> 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.

Sure, I needed to hack a plugin that use the somewhat limited JavaFX 
build tools currently available but allowing to roll maven releases plus 
some other things. I choosed to not use reflection because I needed it 
working quickly and installing the artifact in the local repository made 
everything much easier.

About the dependency to jfx-rt issue that should go away anytime soon. 
This dependency should be declared in the provided scope, meaning that 
even if people will be able to remove it, it should not prevent their 
project to build.

My maven plugin works starting today but is not the panacea, indeed.

> 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 more powerful.
>
> 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).

Having this in separate projects make sense to me. Like you say below 
this would allow different build systems (ant, maven, gradle, sbt ...) 
to reuse this. I agree that it should help with the release cycle issue too.

Downloading needed tools and instrumenting them can surely be done. WiX 
provide a zipped binary distribution without installer and it is command 
line driven so it should be pretty straight forward.

Another example of what could be easily added is producing .deb packages 
for Debian based Linux distributions.

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

Seems to be the way to go and looks exciting.
I'm in, waiting for the JavaFX build tools to be opensourced, then we'll 
see what's next.

/Paul