JavaFX Maven Plugin

[Daniel Zwolenski]

Hey guys,

Is there any more news on the open sourcing of the packaging tools? It's
been a "few days away" since October 27.

I have made some good progress with the JavaFX Maven Plugin. It now
supports a lot of stuff Maven users would expect and could potentially
reduce the barrier to entry for a lot of people to using JavaFX, especially
Maven users (i.e. the bulk of the JEE community). I've written a blog post
showcasing some of the more useful features here:
http://www.zenjava.com/2012/11/24/from-zero-to-javafx-in-5-minutes/

I have also made in-roads into getting it so that WiX can be downloaded
automatically for users when needed, instead of the current, very non-Maven
need to manually install it. I have permission (or at least recognition and
no objections) from the WiX devs to put the zip of Wix in the Maven repo.
I'm half way through the motions of making this happen.

Unfortunately the JFX native bundler code is totally hard coded for a lot
of things it shouldn't be and I am going to have to build my own so I can
use the downloaded WiX (the jfx packager assumes it is on the system path).
I think using Velocity templates I can make a more
powerful/customisable/extensible native bundler anyway, so rewriting this
was already on the cards and it doesn't look overly complicated.

What I'd really like to not have to rewrite are the native launcher
executables that get bundled into the installers (i.e. the "exe" on
windows). I can rip these out of the Java bundle for now to do my
development but I won't be able to release my improved bundler until these
bits are open sourced, giving me the legal all clear to include them in my
plugin.

Any chance I could get an actual timeframe on when the packaging tools are
to be open sourced?

I'm doing my best to contribute what I personally think is vitally
important for JavaFX. In general I'm accepting of the fact that what I'm
doing is not something Oracle sees as overly important and I'm on my own
(it's been quite a liberating attitude to take to be honest). Open Sourcing
the packaging tools however, was something you said you were going to do
anyway and it would save me having to write a whole new native launcher for
each platform.

Cheers,
Dan








On Thu, Nov 15, 2012 at 12:46 AM, Paul Merlin <paul at nosphere.org> wrote:

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