Find (or write) and use a Gradle JavaFX plugin to simplify builds

[msgilligan]

I've looked at the JavaFX Gradle plugin choices out there and am not happy. I wish that Gradle, Inc. would produce or bless one that does the complete job. My understanding is that the leading plugin https://bitbucket.org/shemnon/javafx-gradle is not being maintained (last update 2014)

This is a problem for the whole JavaFX ecosystem and affects more than just GroovyFX. Maybe I'm wrong -- I'd be happy to find out that I am.

So my intention for this issue is that it be for tracking and discussing a solution for GroovyFX. Whatever the best available plugin(s) for JavaFX is (are) we should probably be using it.

A plugin may or may not help with Issue #31. But I think many (most?) GroovyFX apps will want to build bundled Mac OS X apps, bundled Windows .EXEs, etc.

I'm a long-time Groovy developer that is new to JavaFX and I'm looking at GroovyFX as a place to learn beast practices -- e.g. steal a nice build.gradle file.

[russel]

Given that JavaFX come integral with JDK9, this is likely a JDK8 issue only which maybe why no-one has picked up the plugin. @ysb33r (Schalk Cronjé) would undoubtedly be the person to advise as to what would be the best route to take here: fork @shemnon (Danno Ferrin) code, start again, hack for now.

[msgilligan]

Actually the @shemnon plugin is mostly focused around building native-style release packaging for the various platforms. It is very valuable/useful, but is difficult to maintain because it is very complex and platform dependent. Oracle provides the core functionality, I believe but not in a good form.

My goal is to make a JavaFX app with Groovy in it and put it in the Mac OS X app store!

[russel]

Does OSX have JDK8 installed?

[msgilligan]

No, the Gradle plugin actually bundles the JDK inside the app. So you get a native-looking standalone app with no external dependencies. Downside is it's a big file. I'm hoping this will be improved when we get to JDK 9. My app is 200 MB -- but I haven't tried any trimming -- of either the JDK or the libraries that I'm using. There are mobile apps that weigh in at more than 200MB these days, though. I think it's worth it so that end users don't know it's a Java app.

[ysb33r]

I've looked at the JavaFX Gradle plugin choices out there and am not happy. I wish that Gradle, Inc. would produce or bless one that does the complete job.

@msgilligan What do you define as the the complete job?

I'm also wondering what approach Griffon has taken to building JavaFX apps.

[msgilligan]

I would include building native apps for Mac OS X, Windows, and Linux as the @shemnon Gradle plugin does. Maybe it would even include Android and iOS, with the Gluon plugin.

I realize my expectations are high. And as I said before, I think this is a JavaFX ecosystem issue, not a GroovyFX issue. I'd just like to see GroovyFX (and Griffon) encourage and/or adopt the best solution.

[msgilligan]

I'm working on building an app for Mac OS, Win, and Linux in the first set of releases and may be adding Android and iOS. I'm currently shipping (private alpha) a "native" (i.e. bundled JRE) Mac OS X app and shadow jars for Windows and Linux. I hope to get a windows EXE working later this week and Linux in a future release.

I'm currently using the @shemnon plugin, but am prepared to switch. I'd be willing to contribute any code or knowledge I discover (develop, test) to this project and I'm willing to test and debug any new contenders for the JavaFX Gradle Plugin throne, but I don't think I'm in a position to actually develop such a plugin at this time.

[aalmiray]

As I recall form @johanvos, the JavaFX plugin from @shemnon and the jfxmobile from Gluon follow different approaches to deliver the same behavior. These two plugins are incompatible with one another so don't try setting them up in the same project.

Griffon uses the plugin from @shemnon because it was the one available first and it does not force the usage of Retrolambda and other dependencies that the jfxmobile does. Basilisk otoh requires the jfxmobile plugin.

This is indeed a problem of the JavaFX community as @shemnon no longer works on the plugin. He was also in charge of the Maven plugin, which has seen little activity too. Ideally we'd have a JavaFX plugin that dleivers the bare minimum functionality (compile, package native) and an enhanced plugin (jfxmobile) that builds on top on the previous and supports retrolambda, android and more. The only way to make this happen is to get Gluon on the table and discuss options.

[msgilligan]

That is a very clear explanation of what I think I've managed to figure out. (I've tried both plugins on different projects but never tried to mix them.)

How do we best approach Gluon? Do you know them?

[aalmiray]

Yes, I just did over twitter https://twitter.com/aalmiray/status/735041277981544448

[hendrikebbers]

A problem withe the plugin by @shemnon is that it adds the jfxrt.jar to the classpath. That was cool for Java < 8 but with Java 8 you will have the JFX classes 2 times on the classpath. Don't know if this can end in a constellation that will include 2 different jfxrt.jar (if you have several Java 8 versions installed)

[russel]

Also note that OpenJDK 8 doesn't have jfxrt.jar (doesn't have JavaFX at all, only the Oracle distribution does) and OpenJDK 9 has JavaFX but not as jfxrt.jar.

[msgilligan]

I see that @aalmiray has updated the master branch to require JavaFX 11+ and use the JavaFX Gradle Plugin. These are good decisions given that it is now 2020 and JDK/JavaFX 11+ is a reasonable, forward-looking solution.

The JavaFX Gradle Plugin still has some flaws for libraries (notably openjfx/javafx-gradle-plugin#85) but hopefully they will be resolved.

Closing...