...and they shall know me by my speling errors.

Danno Ferrin (aka shemnon) on stuff that matters to him.

JavaFX Gradle Plugin 0.3.0 Released

Today I pushed the fourth rerelease of my JavaFX Plugin for Gradle to bintray, version 0.3.0 (real software engineers count from zero). New in this release is the ability to specify a particular JVM to package with your native bundles and the ability to customize platform-specific build options. Some configuration options and conventions also moved around to support these two features, most notably the plugin no longer automatically self-signs the code.

To use the plugin in your gradle script, you can apply the plugin from the following URL:

apply from: "http://dl.bintray.com/content/shemnon/javafx-gradle/0.3.0/javafx.plugin"

Or, you can include the content of that file anywhere in your build, either directly in build.gradle or included from your file path.

Specifying the Java Runtime

In the more recent Java 8 builds they introduced the ability to specify which Java runtime to use in the Ant tasks via the j2se attribute on the platform tag. Mysteriously enough, it is not available for the command line javafxpacjager tool. To use it in the gradle plugin simply specify the javaRuntime value in the javafx block and point it at the file location of the JDK/JRE you want to ship, like so

javafx {
    javaRuntime = '/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/'

Why would you want to specify a runtime other than the one you are compiling against? Here are a few ideas: You build on Java 8 but ship on Java 7, you need to load some special native libraries or classes such as export restricted cryptography, or you are stripping out things you are not required to redistribute, such as rmid or cobra stuff, or you are adding something like tools.jar. The biggest reason has yet to see wider distribution: you are shipping a Java 8 Compact Profile as the JRE.

The most interesting value, however, is the NO_RUNTIME value (expressed as a string as '<NO RUNTIME>', but the constant is better in case the value changes). Your native packages will be built without a JVM and will instead use the JVM loaded on the local machine. This is very useful for shipping Java 8 examples before it’s release in 2014.

Configuration Profiles

Some of you can probably guess why I am talking about profiles next. By specifying a JRE location in the build file what have I done? I have effectively locked the build down to only work on Mac. New in the 0.3.0 release is a profiles block underneath the javafx block. In this block, you can create custom build profiles and change which ones are used at build time. When looking up convention files the values stored in the profiles are always used before the other values, and they are used in the order the profiles are activated. As a convention, the plugin always adds what platform you are building as the last profile activated. Here is an example from the Fully Expressed sample:

javafx {

  profiles {
  // not every possible platform override, but ones that have a known impact
    windows {
        id = 'c533f663-1efd-489f-b910-4c7ec20c7fd0'
        category = 'JavaFX Demos'
        javaRuntime = 'C:/Program Files (x86)/Java/jdk1.7.0_21'

    macosx {
        id = 'net.java.openjdk.openjfx.Ensemble2'
        category = 'public.app-category.developer-tools'
        javaRuntime = '/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/'

    linux {
        // linux doesn't care about id, it goes un-used at the moment
        category = 'Development'
        // good luck finding a standard location for the JDK
        //javaRuntime = '/usr/lib/jvm/java-7-oracle'
  //---8<-- snip -->8---

I’ll plan on doing a post later for profiles in more detail, but for now it is sufficient to say that the windows, macosx, and linux profiles magically turn on based on where you do the build. No, you cannot use profiles to build a RaspberryPi deb package on a linux box yet, I tried. The problems are deeper than JRE selection.

Convention changes

I also took the opportunity to change some of the conventions. First and foremost I turned off the automatic generation and use of self signed certificates. The 7u21 changes have made those certs next to useless. You can still use the plugin to sign your application with a real certificate, you just have to explicitly do it.

If there is anyone within the sound of my voice that uses the plugin or would want to use the plugin to do real signing of their applications, let me know and I’ll write up some documentation. Until then just know that it can be done.

The next set of conventions has to do with the jfxDeploy task. Every single parameter has been moved into the javafx block and the preferred way to configure those is to use that block. You can still configure them in the task, but the convention block is the preferred location. The FullyExpressed example reflects those changes

Finally, I am dropping the magic auto-updating url. All plugin URLs are version encoded. Really, this is a good idea to avoid surprise breakages and has nothing to do with bintray not letting me delete releases over 30 days old. Honest.


My aim is to make the JavaFX Gradle Plugin a one stop shop for all your JavaFX build needs. If you have any complaints, concerns, requests, code to contribute, or other comments, please let me know by posting an issue on bintray, mail (danno.ferrin@shemnon.com), Twitter (@shemnon), pull request at bitbucket or by leaving a comment in this blog.