Build logic renovation?

[Nir Lisker]

Sorry for the late reply, I was stuck abroad due to flight cancellations :)

This issue has been brought up before, including lengthy off-list
discussions. As a result, I created an umbrella issue that collects issues
regarding the Gradle file: https://bugs.openjdk.org/browse/JDK-8344728. The
linked issues below are a;ready listed under this umbrella issue.

I, like you, was in favor of modernizing the Gradle approach. Johan Vos was
in favor of using the OpenJDK approach with config/make, which I'm not
familiar with (I only built OpenJDK once and many years ago). I believe the
informal verdict is to go with Johan's approach, which I'm fine with.

Regardless, the Gradle file does more than building; it also contains
publishing: https://bugs.openjdk.org/browse/JDK-8333146 (see the PR in the
comments). So, there's more than the build logic to clean up.

I've done some minimal simplifications to the Gradle file in
https://bugs.openjdk.org/browse/JDK-8345063 (I'm not sure a catalog, as you
suggest, would be a big improvement) and
https://bugs.openjdk.org/browse/JDK-8344906. Splitting the file for each
module (subproject) is also mentioned in the umbrella issue: "Splitting of
the monolithic build file should be done with convention plugins. These
encapsulate shared code that can then be applied to subprojects as needed."

I believe that many of these cleanups still hold value since we'll need to
"decipher and translate" the Gradle file to the OpenJDK approach, and it
will be easier to deal with it after cleanups. If I'm correct about this,
then simplifications to the Gradle build file(s) in some areas could still
be welcomed. I'd venture a guess that simplifications that make the code
more readable are desired, but maybe those that dig further into
Gradle-specific approaches (like the new declarative Gradle or the native
plugins) are not.

Would like to hear thoughts on this.

- Nir

On Thu, May 29, 2025 at 8:20 AM Jesper Skov <jskov at mada.dk> wrote:

> Ah, good insight!
>
> Sounds like a renovation of the Gradle file is not really a move forward
> then.
> Cheers!
> Jesper
>
> May 27, 2025, 21:29 by john at status6.com:
>
> > 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250603/84642ccd/attachment.htm>