Hi, Jesper. My comments below are not meant to discourage you entirely
from your plans -- really! :-) -- but rather to help you understand,
based on my own experience, the scope of the work involved.
On 5/27/25 6:41 AM, Jesper Skov wrote:
Would there be interest in reworking the build logic?
Yes, but perhaps more like this:
Building OpenJFX using JDK
https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/
All the procedural Gradle in one large file makes it hard to understand the
build logic.
Indeed.
It looks very complex.
It is very complex.
And it may be performing below optimum (this is just a conjecture).
Without a doubt.
I know that the current build is very obviously working.
Barely. :-)
And that there may good reasons to keep it in its current form.
No, not really, except for the "very obviously working" part.
But if there is an interest, I would like to make the build more idiomatic
Gradle.
Personally, I'm done with Gradle for any of my own projects. It's
difficult to pin down precisely the way in which Gradle fails to be a
good build system, but I think Bruce Eckel summarized it best in his
article below:
Jan 2, 2021 - 16 minute read
The Problem with Gradle
https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/
Changing the build would be an explorative and iterative task.
The JavaFX build system is remarkably complicated. It is based on Gradle
but also uses other build tools such as Apache Maven, Apache Ant, GNU
Make, CMake, Ninja, GNU GCC, Apple Xcode, Microsoft Visual Studio, and
even Windows batch files. It runs on Linux, macOS, and Windows, and
supports eight different hardware architectures (last time I counted).
Testing requires you to configure and run hundreds (!) of these complex
builds and unit tests on multiple systems under Linux, macOS, and Windows.
I'm tempted to say that having (almost) reproducible builds in JavaFX
would help in verifying that you're creating the same artifacts before
and after, but there are just so many artifacts to verify. It's not one
build that produces a set of artifacts. Rather, it's multiple builds
that produce multiple sets of artifacts on multiple systems.
And I would need to know if there are some non-obvious out-of-tree features
that need special handling.
Almost everything in it needs special handling.
I can understand if you would be wary about this proposal; I may not be able to
complete the transition from the current to a new build.
I think you're looking at a multi-year project.
John