I wanted to get this out there early, since “release early release often” is one of the open source mantras. I have a longer blog post planned on this subject, but I have so many balls in the air right now I’m not sure when I’ll get to write it.

I am starting to write a JavaFX 2.0 Gradle Plugin over at bitbucket. Right now it handles just the fx:jar and fx:deploy ant tasks. And not completely. I don’t have the resources wired into the native bundles. But that will come. I also am not doing binary CSS or Jar signing.

There are two samples in the repo demonstrating the build. I pulled from the JavaFX 2.2.0 Samples brickbreaker and Ensemble2 which represents a small and large project. I moved the files around into a conventional layout, and provided the barest of Gradle scripts I could, with the help of the plugin. The script for brickbreaker is awesomely short. And Ensemble2 is a bit longer because of the custom build work it is doing to bring the source of the samples into the jar. When you run ‘gradle assemble` it will actually create the Mac OSX .app and .dmg files. It probably does the correct thing on Linux and Windows but I haven’t tried yet. But first you need to install the plugin via ‘gradle install’ in the plugin dir.

Conventions

My main purpose in this exercise is to try and nail down a set of file layout conventions that Gradle and Maven can use to create a shippable app with a minimum of configuration. Layouts that match the Maven way for the most part. And Ant scripts can be written to these conventions. If, you know, Ant is your thing.

The only out there conventions would be the bundle resources, which I am placing in src/main/resources. I also intend to add some other standard files, like src/main/resources/icon.png and associated files and directories being loaded into the proper place for native bundling. I also need to figure out what to do about signing keys. Likely this will have to be a configuration thing since checking in your signing key to source control would be a bad idea, even if you have the world’s most awesome password.

Finally, I have zero intention of writing this hypothetical Maven plugin. Gradle is what I do for fun. I’de rather write Perl scripts than Maven plugins, no offense to the Perl crowd. But being part of the conversation to set the conventions is something I intend to be a part of.