Building OpenJFX.

[Kevin Rushforth]

> While I doubt such issues are “real” I understand that you have to deal with Oracle lawyers.

It might be worth asking again to see whether there are any concerns. If 
we can address them, then maybe this is the way to go.

> 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.

And if not, then this is good alternative.

> 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.
>   

Yeah, that would be a big task, but possibly worth someone looking into 
(as for myself, I consider Windows to be unusable without Cygwin as a 
developer, so it wouldn't occur to me to want to build on a system 
without it). Eliminating the need for ant would require some work to 
refactor the apps, but is conceptually easy.

> 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
>   

We already have a mechanism to point to a (possibly early access) JDK to 
grab the binary from there (see the STUB_RUNTIME variable). It wouldn't 
be too hard to extend that.

Thanks for the suggestions.

-- Kevin



Scott Palmer wrote:
> The project should be configured to use the Gradle Wrapper, so the correct version of Gradle is used automatically.
> https://docs.gradle.org/current/userguide/gradle_wrapper.html <https://docs.gradle.org/current/userguide/gradle_wrapper.html>
>
> 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.
>
> e.g.
> build.gradle contains:
> task wrapper(type: Wrapper) {
>   gradleVersion = '4.3'
> }
>
> one-time setup:
> gradle wrapper
>
> run the build:
> gradlew
>
> 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
>
> Regards,
>
> Scott
>
>   
>> On Dec 19, 2017, at 4:17 PM, Kevin Rushforth <kevin.rushforth at oracle.com> 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 oracle.com>:
>>>  
>>>       
>>>> 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.
>>>>