Deadlines on a shortened schedule are bad enough. Preparing multiple conference talks is also similarly time consuming. What happens when you combine them both? Lower priority items like making release announcements for your outside-of-work open source projects don’t happen on time.

Today I am announcing the release of the Maven JavaFX Plugin version 8.1. Actually, it happened three weeks ago. The current version is already 8.1.2. The Maven co-ordinates for the plugin are com.zenjava:javafx-maven-plugin:8.1.2, same as before just with an updated version number. This release provides compatibility with JDK 8u20, exposes new 8u20 features, and represents a change in maintainer. Docs are little sketchy since I need to find a new place to host them. Existing docs at http://zenjava.com/javafx/maven/ are still mostly accurate.

New Maintainer

Effective with the 8.x series of the Maven JavaFX Plugin, and with the consent of Daniel Zwolenski, I am now maintaining the project. That means I am responsible for getting the binary bits onto Maven central. It does not mean that I am the only one allowed to write code. Already a lot of the changes in this release come from community members. Please, keep the pull requests coming.

This also represents a change in philosophy for the plugin. This plugin now exists as a means for Maven to access the features of the Java Packager, which started life as the JavaFX Packager. The Java Packager can still be used to package JavaFX applications, but it can also package SWT applicaitons, AWT applicaitons, headless applications, and good old Swing applications. In fact, it can help you put Swing applications on the Mac App Store. Patches that move the plugin from this lean-and-mean approach will be politely declined. I think there is enough space for packaging plugins that don’t make self-contained native applications and JNLP packages. On the same note, patches that help the plugin live together with other plugins will be favorably considered.

Support for 8u20

The major feature of this release is compatibility with the changes done in Java 8u20. A lot of internal structure was changed to make sure that the java packager could be used directly by IDEs and other build tools, and as a consequence some binary compatibility was broken. Since this plugin is dependant on ‘internal’ Java APIs, e.g. packages in the JavaFX modules that start with com.sun and com.oracle such breakage should not be suprising as Sun, and then Oracle, has expressly reserved that right.

This means that some lineages of the plugin will become ‘version-locked’ with the particular versions of the JDK. The 2.0 line works with Java 7 and Java 8, 8u5, and 8u11. The 8.1 series will work with 8u20 through any version less than 8u40. When 8u40 comes out, a new 8.2 version will be released, so on with 8.3 and 8u60 and so on. The 8.1 and 8.2 versions may work with each other, and they may not. I honestly don’t know at this point. But the 8.1 version of the plugin and anything less than 8u20 doesn’t work, similarly with 2.0 and anything after 8u11.

Exposeing Configuration Options

There as some existing JavaFXPackager configuration options that have been exposed to the plugin in the config element.

• Added needsShortcut and needsMenu parameter to set the presence of a launch/start menu icon or a desktop icon for bundlers that support it
• Added an appName parameter so you can customize the app name independent of the Maven project name.
• Added a userJvmArgs parameter, following the Maven map conventions, so you can provide JVM arguments that can be adjusted by the application at runtime.
• Added a bundleArguments parameter, following the Maven map conventions, so you can pass arbitrary configurations to any of the bundlers.

Future Proof the Bundlers

This last parameter is the most relevant one for future-proofing the plugin. This is used for things like your Mac App Store signing identities, and platform specific icon files.

All of the named parameters can be mapped to bundleArguments configuration elements. However, not everything useful to put into this parameter can be mapped to other parameters. This exists for bundler specific configurations that are not relevant to other bundlers. For example, Windows doesn’t care about the maintainer e-mail, but Debian bundlers have a space for it and Ubuntu cares very much about it.

This also allows for new bundlers that we didn’t know about when we wrote the packager to ask for new configurations. For example, if someone wrote a packager and loader for Lego Mindstorms EV3 then the bundler could require the name of the brick or the Bluetooth MAC to upload the pacakge.

Looking Forward

This plugin will continue to support newer versions of the Java Packager. For example, work done for JEP-208 will require plugin additions to support the features of Multiple Entry Points and File Associations, since there is no string-based mapping of the bundle arguments for those.

As I mentioned earlier, the numbering conventions for the version string will mirror what version of the JDK it is designed to support. There were no major changes in the FCS of Java 8, so there was no 8.0 release series. The 8.1 release series will support 8u20 and security patches based off of it. The 8.2 series of releases (expected to start around March 2015) will support 8u40 and security updates, so on and so forth with 8u60 and all other feature release versions that may happen.

For Java 9 I may consider some more naming changes. Java 9 is scheduled to contain major modularization changes via Jigsaw (these are foward looking statements, safe harbor provisions apply, the surgeon general warns that you shouldn’t believe everything you read on the internet and in blogs, etc. etc.). This repesents a major milestone for Java and a major rethinkning of the way the JRE is packaged. Hence it may prompt a name change (to just the Maven Java Packager Plugin) as well as a group name change (to com.example.not.sure.yet or something else). Then again, it may not. I have over a year to decide. But for the 8.x series I’m sticking with Maven JavaFX Plugin and com.zenjava.

Contributions Welcome

For this release I merged in every outstanding pull request that looked reasonable and was consistant with the philosophy. I don’t have strong opinions about how the plugin should look since Maven isn’t my favorite build tool (but it easily outranks Ant, Make, SBT, and shell scripts) so the odd are that if you send a halfway decent pull request consistent with my ‘enable javapacakger in Maven’ philosophy then it will be merged. When I call myself the maintainer I really mean it in the sense I am rolling a bucket down the halls and mopping the floor after people use it. The users of the plugin are the most important consideration, and I will take those needs in mind as I look at pull requests.