JavaFX Maven Plugin

[Daniel Zwolenski]

Thanks for the feedback Tom. 

I'm bleary eyed and off to bed now (it's been a long week of late night coding) so I'll look at this again in the morning. 

Just briefly though, for the executable jar I believe I'm just following the procedure used by the jfx Ant tasks. So the problems you raise (and great that you raise them) all apply to the ant tasks too. As such it would be good to get input from the Oracle jfx packaging team on your comments - ie what's their take on these problems and what's their solution. 

Not that I'm limited to doing it their way but would be good to hear thoughts on it before going down any particular road. 


On 25/11/2012, at 10:51 PM, Tom Eugelink <tbee at tbee.org> wrote:

> Hey Dan,
> 
> Just read your blog and I think it is great that someone is finally tackling the Maven / installer issue. However, I would like to point one thing out: from the remark about duplicate classnames I conclude that you unpack all jars and repack them into a single jar. This is the only easy way to get a startable jar, but there are a few other catches beside the duplicate classnames. First, some licenses do not allow this repacking and require that you distributed the jar as-is. Secondly, some jars have been signed and repackaging will break them. I ran into all of these when I tried to create a single jar deliverable of my Swing ERP application.
> 
> The better approach would be to use one-jar (http://one-jar.sourceforge.net/) which adds a special class loader to load classes from the jars inside the jar. It's a good and often used solution.
> 
> However, I ran into the problem that this approach prevents the use of certain command line arguments, like -javaagent, because the classloader is not installed when the command line arguments are parsed. So I created an alternative called "app-jar", which basically does what EDI's do and spawns a separate JVM; it unpacks the jar into a tmp directory, then creates a new java JVM and starts that. The initial JVM then goes into a monitoring state, watching the spawned JVM, and as soon as that is stopped, it cleans up the tmp directory. The only catch is that you have to understand this spawning process, because you need to specify "double D's" (which has nothing to do with women) for certain parameters. This is because of the "-D-D" notation being used: "-Dtest" goes to the spawing JVM, "-D-Dtest" is forwarded as "-Dtest" to the spawned JVM. So the "-javaagent" is set as "-D-javaagent".
> 
> Just a suggestion.
> 
> Tom
> 
> 
> On 2012-11-25 12:29, Daniel Zwolenski wrote:
>> 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
>>> 
>>> 
>>> 
>