Where do I find documentation on the plugin?

Create issue
Issue #24 resolved
Jeffrey Guenther created an issue

I would like to learn more about how the plugin works. I've been having trouble with setting it up to work with the application plugin provided by gradle. My main class seems to be erased by the javafx configuration. Do the configurations for the javafx task have default values?

Comments (8)

  1. William Daniels

    Here is my build script, which works with the application plugin + the javafx gradle plugin. It might help! It's far from perfect, but it works like I need it to. You might be able to do either the mainClass variable under the javafx closure, or the one under the java closure, but I opted to do both just to be safe. Also, many of the flags under the javafx closure are, of course, optional.

    apply plugin: 'application'
    apply from: 'javafx.plugin'
    apply plugin: 'java'
    apply plugin: 'idea'
    apply plugin: 'maven'
    defaultTasks  'build'
    test {
        forkEvery = 1
    dependencies {
        compile fileTree(dir: 'gradle-lib', includes: ['*.jar']) 
        compile fileTree(dir: 'lib', includes: ['*.dll'])
        compile fileTree(dir: 'lib', includes: ['*.jar']) 
        compile 'commons-io:commons-io:2.4'
        compile 'dom4j:dom4j:1.6.1'
        compile 'net.sourceforge.jexcelapi:jxl:2.6.12'
        compile 'org.apache.pdfbox:pdfbox:1.8.3'
        compile 'edu.ucar:netcdf:4.2.20'
        compile 'org.apache.poi:poi:3.9'
        compile 'org.apache.xmlbeans:xmlbeans:2.6.0'
        compile 'log4j:log4j:1.2.17'
        testCompile 'junit:junit:[4,)'
    repositories {
    configurations {
    mainClassName = "Mark.Mark"
    def mainAppName = "Whatever_your_app_name_is"
    def versionNumber = "3.1"
    task wrapper(type: Wrapper){
      gradleVersion = '1.10'
    javafx {
        appID '{C15A6650-A798-479A-B8F1-F83C6725BAB7}'
        mainClass = mainClassName
        appName = mainAppName
        jvmArgs = ['-XX:+AggressiveOpts', '-XX:CompileThreshold=1', '-Xlint:deprecation']
        arguments = ['-1', '--fast', '-Xlint:deprecation']
        systemProperties = [ 'prism.disableRegionCaching':'true' ]
        arguments = ['1AC', '1NC', '2AC', '2NC', '1NR', '1AR', '2NR', '2AR']
        embedLauncher = true // caution: class-path not set and is overwritten if set to false
        // applet and webstart stuff
        width = 800
        height = 600
        embedJNLP = false
        // deplpy/info attributes
        category = 'production'
        copyright = 'copyright_info'
        description = 'description_of_your_product'
        licenseType = '3 clause BSD'
        vendor = 'your_vendor_name.'
        // deploy/preferences attributes
        installSystemWide = true
        menu = false
        shortcut = false
        // app icons
        attributes("Main-Class": mainClassName);
    build.dependsOn (docs, assemble, copyResources, copyMenuFXML, copyLog4JFile, copyEXEs, copyExtraStyles, copyRunningDLLS, zipEverything, copyFinalZip)
    task all (dependsOn: [build])

    Whoops! forgot to post up my javafx.plugin script:

     * Bootstrap script for the Gradle JavaFX Plugin.
     * (based on http://plugins.jasoft.fi/vaadin.plugin)
     * The script will add the latest version of the plugin to the build script
     * dependencies and apply the plugin to the project. If you do not want
     * this behavior you can copy and paste the below configuration into your
     * own build script and define your own repository and version for the plugin.
    buildscript {
        repositories {
            maven {
                name = 'BinTray'
                url = 'http://dl.bintray.com/content/shemnon/javafx-gradle/'
            maven {
                name = 'CloudBees Snapshot'
                url = 'http://repository-javafx-gradle-plugin.forge.cloudbees.com/snapshot'
            ivy {
                url = 'http://repository-javafx-gradle-plugin.forge.cloudbees.com/snapshot'
        dependencies {
            classpath 'org.bitbucket.shemnon.javafxplugin:gradle-javafx-plugin:0.5.0-SNAPSHOT'
            classpath project.files("${System.properties['java.home']}/../lib/ant-javafx.jar")
            classpath project.files("${System.properties['java.home']}/lib/jfxrt.jar")
    if (!project.plugins.findPlugin(org.bitbucket.shemnon.javafxplugin.JavaFXPlugin)) {
        project.apply(plugin: org.bitbucket.shemnon.javafxplugin.JavaFXPlugin)

    Also, to answer some of your questions > there is no documentation explicitly listed that I've been able to find, most of this is trial and error. As far as default values, the javafx task does indeed have default values, to find out what exactly they are though, you'd have to tackle the source code and just see what it gets initialized to.

    I have some copy tasks not listed for brevity's sake, so if you copy/paste this it won't work for you due to the build.dependsOn, but I wanted to make sure to include that to point out the build task having the assemble dependency. This lets you just run gradlew (or just gradle, if you don't use the wrapper) to do the entire build, which is rather nice.

    also to note: this is also with the standard maven directory structure, aka: src/main/java/whatever, src/main/resources/whatever, src/test/java/whatever, src/test/resources/whatever.

  2. Jeffrey Guenther reporter

    Thanks @willbdaniels. I was able to figure out how to use the mainClassName variable and pass the info to the javafx closure. Have you had any success passing arguments in via the commandline?

  3. William Daniels

    It depends on which sort of arguments you need to pass in. if you mean like a String literal argument (or perhaps a number that you could parse from a string) you have two options when passing to gradle on the command line. the first is using the -P, the other is --project-properties. Used as such:

    task showArgs << {
        println "$word1 $word2"
     gradle showArgs -Pword1=hello --project-prop word2=world

    Using that convention, you should be able to define variables uninitalized inside of your gradle script, and then pass them in at the command line at run-time. Something like this:

    def myTestVariable
    task variables << {
       myTestVariable = "$word1"
       println myTestVariable
    gradlew variables -Pword1=hello

    Keep in mind, I only know how to pass single words (no spaces) to gradle in a single property, so if you need space delimited words (or sentences) then you'll need to do some concatenation after the fact. Also make sure that anytime you use a convention like this, the tasks that define your variables with the command line MUST run before the others are used, or you could get some really unfortunate undefined behaviour. Good luck! shoot me an e-mail at willbdaniels@gmail.com if this doesn't answer your question, I'll be happy to help where I can.

  4. Jeffrey Guenther reporter

    I'd like to be able to dump args to the executable just like on the commandline. I'm familiar with using -Pargs to set the args of the run task - At a minimum, I have to split the string to get each of the space separated args. My question is specific to the javafx gradle plugin as it seems to overwrite whatever you might expect is going to run's args variable with an empty array. I need to be able to get -Pargs into the javafx closure, so I can set it's runtime args. I would like my javafx application to read a file path in when it starts. It's reading a settings file.

  5. Jeffrey Guenther reporter

    Turns out the error I was running into was the result of an extra set of quotes in my netbeans gradle task descriptions. @willbdaniels thank you for being willing to dive in help. It's much appreciated.

  6. Jeffrey Guenther reporter

    Issue was due to using quotes in parameter values in the netbeans gradle plugin.

    Instead of -Pargs="path/to/something", you can do Pargs=path/to/something

  7. William Daniels

    Hmmm, this is actually an interesting issue, it took a good deal of tinkering for me to find a good way to access a property inside of the javafx task closure, since it seems to be compiled at the very BEGINNING of the initialization phase of the build, it proved to be tricky to find something sufficiently high-level enough to supercede it in priority. Yet, lo and behold, success! Now, you'll need to keep in mind, I consider this a massive hack, and there is probably a more gradle-esque way of doing it that doesn't involve these sort of shenanigans. Also, this batch script is for windows, you'll have to modify it slightly to make it work on linux, if that's where you're building it. (although since the javafx plugin is busted on linux right now, I doubt that ;) ). Alright, so one of the requirements was that you read in a set of variables and pass them into gradle via' the command line. Well, normally you could just use the -P argument with a batch script and call it a day, but since we need something sufficiently high level (aka, happens before the javafx task initializes itself in plugin world), you're going to need to use a gradle properties file. (that is, a gradle.properties). also, you're going to need to pass this all as one huge system property. ew.

    now, for my example, the variables.txt file that you would theoretically be reading from has the same number of lines as my gradle.properties, so it's a touch superfluous to read from a file and then just copy it to a new one. But if you were poaching out specific properties, it would be more useful.

    so first, my variables.txt:

    systemProp.system="This is my new value!"

    Alright, simple enough, now lets look at the custom.bat file:

    @echo off
    set "file=variables.txt"
    set /A i=0
    rm init.gradle
    for /F "usebackq delims=" %%a in ("%file%") do (
    set /A i+=1
    call set array[%%i%%]=%%a
    call set n=%%i%%
    for /L %%i in (1,1,%n%) do call echo %%array[%%i]%% >> gradle.properties

    Alright, excellent, now we have a system property named system that holds the value "this is my new value!". Now, the pertinent part of the javafx closure:

    javafx {
       println System.properties['system']

    whew. Now, if you can imagine with me for a moment, if that system property we defined was in fact a long set of variable values, you could parse it up and finish the definitions inside of the javafx closure, which should give you the expected behaviour.

    alright! Sorry that was so wordy, took a little bit of gradle automagic to make that work. I hope that helps!

  8. William Daniels

    Derp. Well I just say your response. just goes to show that sometimes, the hard solution is NOT the correct one. 10 points for catching that!

  9. Log in to comment