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.rushfo...@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.r...@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.
