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

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

Gradle JavaFX Plugin 0.2.0 Released

The 0.2.0 release of the Gradle JavaFX Plugin is now live on BinTray. Get it while it’s hot! More things changed in this release than the lat time around. First there has been a lot of work automating the use of icons in the packaged resource. My previous post has all the details. Second, the interaction between the Maven and Eclipse plugin has been improved. Finally, the distribution has move to BinTray for the release artifacts.

Changed Conventions

There is one notable change that needs to be called out. Previously package specific resources went under src/main/resources. I have moved them to src/deploy/resources to clarify that they are used for deployment and not at runtime. This was needed for the gradle eclipse plugin to create sensible projects. The sample applications have been adjusted appropriately.

Changed Deployment Info

The plugin is no longer deployed to the webdav repository on CloudBees, but instead has migrated over to BinTray. The new recommend release scripts for the most recent version of the plugin, regardless of version:

1
apply from: 'http://dl.bintray.com/content/shemnon/javafx-gradle/javafx.plugin'

For a version locked script you can use this script

1
apply from: 'http://dl.bintray.com/content/shemnon/javafx-gradle/0.2.0/javafx.plugin'

The repository location and co-ordinates also have changed. If you are using a direct build script dependency you will to use this co-ordinate

1
org.bitbucket.shemnon.javafxplugin:gradle-javafx-plugin:0.2.0

You will likely want to look at the apply script anyway since there are also some other build time dependencies. I wish gradle just had a way to apply plugins from a maven co-ordinate, with dependencies.

Examples

If you would like to see some samples built with the plugin you can download them from the CloudBees repository. Only the single file installers are available. The source is available at the bitbucket project.

Future Plans

For the next release I am planning on spending more time focusing on making the per-platform packaging top notch. I will add in hooks and allowances so that the end user can build any of the packaged platforms without conflict. One example is that the appId means different, incompatible, things on Windows and Mac. Windows wants a GUID whereas Mac wants a CFBundleIdentifier (which is close to a package name). Then there is the issue of gatekeeper and other smaller details.

In the mean time, if you find any bugs please be sure to report them. I can also be found on twitter as @shemnon.

Comments