I haven’t’ done much to promote it yet, but I feel I have written enough to announce that I have written a JavaFX 2.0 Plugin for Gradle. Better documentation will follow, but this is the announcement getting it out there, After all this is just an oh dot oh dot oh.

Real Computer Scientists Count from Zero

Why the 0.0.0 release? Well, real computer scientists count from zero. The vending machines in the computer science building at my university started with zero on the left, then one and two and so on. And when software is released the ‘oh dots’ precede the ‘one dot oh’, clearly establishing that the digit on the right should be zero. So why are first releases 0.1 or 0.0.1? It’s not the second release, it’s the first release! So start at the first index: Zero! Why three numbers? I blame OSGi. And blame is the correct word, not credit.

All silliness aside, the plugin is actually useful. It takes care of a lot of the JavaFX package stuff, you know, magically. Magically in the sense that if you saw it happen you would know what is going on, but you don’t see it so you applaud and say ‘what a neat magic trick.’

Getting Started

I’m going to assume you already know a little about Gradle, and also that you know about the src/main/java and src/main/resources conventions from Maven. Once you set your source files up in those directories set up your build.gradle file by installing the plugin. There are two options for installing the plugin: you can apply it explicitly, or you can use a nifty script shortcut I learned from a Vaadin Gradle plugin I found.

Short way:

Long way:

The short way just brings in a script from the repository that does everything the long way. The advantage of the long way is you won’t get surprised when the JavaFX plugin gets updated to the latest version. The advantage of the short way is that it is more terse (except that the url is kinda long).

Configurations and Conventions

Remember two weeks ago when I talked about Conventions and Configurations? Well, if you named your main class Main and placed it in a directory matching the directory of your project, your configuration is done. No, Really!. The package is actually the group of your project, which can be set via a group = 'com.example.whatever' statement in your script. You can also name the main class whatever you want via the javafx convention.

The documentation for the JavaFX conventions and tasks are the weakest part right now, but I have an example that I use for smoke testing that shows everything that ought to be configured, but most items don’t need to be.

Tasks

Since the JavaFX plugin also use the Java plugin it gains all the tasks and configurations from that plugin, and it adds a few more tasks of it’s own. Most of them you can ignore and take for granted that they work, but there are two principal tasks you will be interested in targeting directly.

The first task is the standard assemble task, and like the name implies it assembles the jar and the native packages. The resulting files will wind up in build/distributions/bundles and will be limited to the particular platform you happen to build on. It will also use the JDK you ran Gradle on as well. It also creates JNLPs and signed the jars, but don’t get too excited as it still requires some hand tweaking of the JNLP file to make work. Remember what version number this is…

The second task that would be relevant is the run task, provided by this plugin. This runs the JavaFX application in situ without any packaging beyond complication and resource preparations. This is useful during the build-test-tweak loops. More interesting is the debug task, but you will have to run that with the NetBeans Gradle plugin to get the full effect.

Builds

I am creating the builds and hosting the repository on CloudBees, who was kind enough to offer free OSS hosting for build and repository distributions. I wear both of the shirts I got from them at JavaOne on a regular basis. I have a Jenkins Build Server building the samples and deploying the plugin to the snapshot and when appropriate release repositories. And they are ivy repositories because Maven 3 snapshots are so beyond messed up it is unreal.

Feedback Welcome

The code itself is hosted on BitBucket which has a nifty issue tracker that is not quite as awesome as JIRA, but serves the purpose. If you have any issues or suggestions for improvement feel free to post an issue. Or post a patch, or a pull request.

All feedback is fair game. If you don’t like the way I am doing the conventions please speak up. I am not interested personally in breaking new conventional ground or having style arguments, but I am interested in following how other similar build systems set up their builds and conforming when it makes sense.

And one last thing: it’s not the rottenness of the tomato that is thrown, but the technique that matters. A well articulated piece of feedback generates more interest than stuff like ‘LOL JavaFX’, which just makes you look like an ass.