Building OpenJFX.

Scott Palmer swpalmer at
Tue Dec 19 22:04:50 UTC 2017

The project should be configured to use the Gradle Wrapper, so the correct version of Gradle is used automatically. <>

There was some concern about checking in the gradle-wrapper.jar file, and potential licensing issues.  While I doubt such issues are “real” I understand that you have to deal with Oracle lawyers.  Perhaps a solution then is to configure the wrapper via a setup step to run the wrapper task with any version of gradle that can handle it, then run the gradlew script that it generates.

build.gradle contains:
task wrapper(type: Wrapper) {
  gradleVersion = '4.3'

one-time setup:
gradle wrapper

run the build:

Gradle bumps should be able to happen any time without causing issues.  Gradle becomes just another dependency that is automatically fetched. A simple check to make sure the Gradle version is okay can be coded into the build script, e.g. something like:

def blessed_gradle_version = '4.3'
task wrapper(type: Wrapper) {
  gradleVersion = blessed_gradle_version
if (project.gradle.gradleVersion != blessed_gradle_version) {
  println "Build expects ${blessed_gradle_version} but found ${project.gradle.gradleVersion}\n Run 'gradle wrapper', then use 'gradlew'"
} else {
  apply from: 'real_build.gradle'

Gradle incompatibilities should be rare anyway.

What I would really like to see, and I know I’m asking for a lot, is the elimination of the Cygwin requirement and the use of the Gradle native plugin for the native code (maybe we can exclude WebKit from that for now)
You shouldn’t need Ant either.

It should be easy to build without WebKit and have pre-built WebKit binaries pulled in like any other dependency instead, based on a build property. E.g. gradlew -PusePrebuiltWebKit=true



> On Dec 19, 2017, at 4:17 PM, Kevin Rushforth <kevin.rushforth at> wrote:
> Building WebKit is challenging, to be sure. I hope to enlist the help of some of our WebKit team members to review (and contribute to) update build instructions to help make it a little less painful, but it is still a challenge.
> As for the moving version of gradle, we so far have settled on a specific version for each release family: gradle 1.8 for JDK 8u, 3.1 for JDK 9, and 4.3 for JDK 10. We don't tend to bump it.
> Thanks for the feedback.
> -- Kevin
> Mario Torre wrote:
>> For me the most intricate part is about building the webkit based
>> code, especially on RHEL/CentOS. I admit I didn't try with the very
>> latest code drop though. The moving version of Gradle is also an
>> issue, since we try to use a stable toolchain on those OSes.
>> Cheers,
>> Mario
>> 2017-12-19 21:11 GMT+01:00 Phil Race <philip.race at>:
>>> In the "innovation" email thread it was suggested that one obstacle to
>>> getting involved and contributing to OpenJFX is just building it.
>>> So what are the top one or two pain points with building OpenJFX today ?
>>> - Insufficient or out-dated build docs ?
>>> - Tool-chain configuration problems - platform-specific or otherwise ?
>>> - Needing to do a JDK build as well (JDK 9 and later) ?
>>> - Something else ?
>>> And having identified your pain point(s), what do you think would be a
>>> solution ?
>>> -phil.

More information about the openjfx-dev mailing list