It’s fair to say my existing JavaFX Maven plugin code is downright ugly. A combination of trying to cover too much ground, knowing too little about Maven at the time, and having to work around all the horrible nasties in the current packaging tools led to a code base that was pretty much unusable. I’m pretty impressed that a few of you managed to contribute fixes and enhancements!
I’ve been holding off fixing things however, as there were rumours that the JavaFX packaging guys were planning to significantly rework their tools, finally giving it the attention it desperately needs. Sadly, it seems that the packaging guys have again been dragged off into the land of tedious bug fixing. So I’ve given up waiting, and I’m now a good way through overhauling the JavaFX Maven plugin.
I’ve just put up a a 2.0 alpha-release of the plugin. This is a complete re-write from the ground up and it takes some radically different approaches. Given these changes I’m looking for two things: I need people to test this new code (especially on multiple OS’s), and I need feedback on some of the more significant changes as to whether people think these are good or not. It’s not too late to change things if needed.
Below are the steps to needed to use the 2.0 snapshot release. Further down, I list some of the more significant changes to the code – if anyone is a previous contributor, or wants to be a future contributor, you may want to read through this.
One of the good things about the new code base is that I can now generate the standard Maven docco for it (although I still need to actually document a lot of things). I’ve uploaded the current version to here: http://zenjava.com/javafx-maven-plugin/plugin-info.html
Using the 2.0 Snapshot Release
Add the Sonatype Snapshot repository to your POM:
<pluginRepositories>
<pluginRepository>
<id>sonatype.snapshots</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
<releases>
<updatePolicy>daily</updatePolicy>
</releases>
<snapshots>
<updatePolicy>daily</updatePolicy>
</snapshots>
</pluginRepository>
</pluginRepositories>
Change your POM to use version 2.0-SNAPSHOT of the JavaFX Maven Plugin. In general most of the configuration options are unchanged, but if you’re using signed web-based deployments, you also need to change the ‘permissions’ element to ‘allPermission’. This is more inline with the way the JavaFX Packaging tools need it to be.
<plugin>
<groupId>com.zenjava</groupId>
<artifactId>javafx-maven-plugin</artifactId>
<version>2.0-SNAPSHOT</version>
<configuration>
<mainClass>com.yourcompany.YourApp</mainClass>
<allPermissions>true</allPermissions>
...
</configuration>
</plugin>
Additionally the commands for building things have changed. Partly this is to be more in-line with Maven’s naming conventions but also some commands have merged or been significantly changed. Here’s the list of commands:
mvn jfx:jar — this replaces build-jar, unlike before it does not merge everything into one uber-jar, instead it creates a ‘lib’ directory for dependencies and the manifest references these
mvn jfx:native — this replaces build-native and will build a native installer based on the settings
mvn jfx:web — this replaces build-webstart and it now uses the JFX packaging tools directly instead of templates, it build both a webstart and applet output
mvn jfx:fix-classpath — puts jfxrt.jar on your JVM’s classpath, same as before
mvn jfx:generate-key-store — generates a testing key store for you, same as before
mvn jfx:run — starts your app, same as before
That’s it at this stage. From a user’s perspective, the main thing is we don’t bundle everything into an uber-jar anymore (this was the root cause of many problems for many people).
Additionally I am now using the JavaFX Packaging tools directly for the web stuff, which is both good in that you get more features (like applets, etc) but bad in that you lose the powerful templating system that I had before. I’ve done this mostly for ease, and if people really want the templating system back in, let me know and we can look into it.
What I really need is for you guys to have a crack at using this new plugin and the new commands and tell me firstly if it works or blows up, and secondly if you like it or hate it. You can either comment on this post, or raise issues in GitHub.
Changes in the 2.0 Codebase
If you were one of those brave few who managed to work out the old codebase, the good news is, the new stuff is MASSIVELY simpler. The new codebase is now down to a few, nice, self-contained classes: https://github.com/zonski/javafx-maven-plugin/tree/master/src/main/java/com/zenjava/javafx/maven/plugin
Firstly, I’ve done the reflection completely differently. So now the code all makes direct calls onto the JavaFX packager library, instead of using the script-style invoke(target, “method”, param1, param2). This alone should make it significantly easier to work with the code, and people should be able to make contributions much more easily.
The next big change is that I’ve ditched the idea of using the javafx-deploy-lib. The point of this was to allow re-use between multiple build tools so others (such as those writing the Gradle plugins, etc) could try and use it. Turns out no one was too interested in doing this, and since it just complicated things for us in Maven land, I’m dropping it. Any code that was needed from this has now been brought into the plugin code base and references to the deploy lib are gone.
Additionally, I’ve also improved the inheritance hierarchy between the different Mojos. So each one now defines it’s own parameters instead of them all being defined in a common base class. This means each Mojo now only lists the parameters that are relevant to it, and the generated documentation now starts to be useful (before it looked like every param could be used everywhere).
Finally, I’ve done away with the uber-jar code. This previously unpacked and re-jarred all the dependencies into one big, executable jar. It seemed like a good idea at the time but turns out there are libraries out there that have files named the same way in them, and things like manifests get quickly trashed. All in all, this approach was a pain. The new approach now just uses an external ‘lib’ directory where all the runtime jars are copied to, and the manifest in the main app jar points to this.
There’s a few other minor changes and fix-ups that I’ve done on the way, but these are the main things. It would be great to get some feedback on the updated code. I’m also hoping that this will open up the door to more people contributing, as it is now quite trivial to wire in a parameter or setting that’s not done yet. If you need it, add it.
Continue Reading→
