<div dir="ltr">Sorry for the late reply, I was stuck abroad due to flight cancellations :)<div><br></div><div>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: <a href="https://bugs.openjdk.org/browse/JDK-8344728">https://bugs.openjdk.org/browse/JDK-8344728</a>. The linked issues below are a;ready listed under this umbrella issue.</div><div><br></div><div>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.</div><div><br></div><div>Regardless, the Gradle file does more than building; it also contains publishing: <a href="https://bugs.openjdk.org/browse/JDK-8333146">https://bugs.openjdk.org/browse/JDK-8333146</a> (see the PR in the comments). So, there's more than the build logic to clean up.</div><div><br></div><div>I've done some minimal simplifications to the Gradle file in <a href="https://bugs.openjdk.org/browse/JDK-8345063">https://bugs.openjdk.org/browse/JDK-8345063</a> (I'm not sure a catalog, as you suggest, would be a big improvement) and <a href="https://bugs.openjdk.org/browse/JDK-8344906">https://bugs.openjdk.org/browse/JDK-8344906</a>. 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."</div><div><br></div><div>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.</div><div><br></div><div>Would like to hear thoughts on this.</div><div><br></div><div>- Nir</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, May 29, 2025 at 8:20 AM Jesper Skov <<a href="mailto:jskov@mada.dk">jskov@mada.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ah, good insight!<br>
<br>
Sounds like a renovation of the Gradle file is not really a move forward then.<br>
Cheers!<br>
Jesper<br>
<br>
May 27, 2025, 21:29 by <a href="mailto:john@status6.com" target="_blank">john@status6.com</a>:<br>
<br>
> 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.<br>
><br>
> On 5/27/25 6:41 AM, Jesper Skov wrote:<br>
><br>
>> Would there be interest in reworking the build logic?<br>
>><br>
><br>
> Yes, but perhaps more like this:<br>
><br>
> Building OpenJFX using JDK<br>
> <a href="https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/" rel="noreferrer" target="_blank">https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/</a><br>
><br>
>> All the procedural Gradle in one large file makes it hard to understand the build logic.<br>
>><br>
><br>
> Indeed.<br>
><br>
>> It looks very complex.<br>
>><br>
><br>
> It is very complex.<br>
><br>
>> And it may be performing below optimum (this is just a conjecture).<br>
>><br>
><br>
> Without a doubt.<br>
><br>
>> I know that the current build is very obviously working.<br>
>><br>
><br>
> Barely. :-)<br>
><br>
>> And that there may good reasons to keep it in its current form.<br>
>><br>
><br>
> No, not really, except for the "very obviously working" part.<br>
><br>
>> But if there is an interest, I would like to make the build more idiomatic Gradle.<br>
>><br>
><br>
> 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:<br>
><br>
> Jan 2, 2021 - 16 minute read<br>
> The Problem with Gradle<br>
> <a href="https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/" rel="noreferrer" target="_blank">https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/</a><br>
><br>
>> Changing the build would be an explorative and iterative task.<br>
>><br>
><br>
> 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).<br>
><br>
> Testing requires you to configure and run hundreds (!) of these complex builds and unit tests on multiple systems under Linux, macOS, and Windows.<br>
><br>
> 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.<br>
><br>
>> And I would need to know if there are some non-obvious out-of-tree features that need special handling.<br>
>><br>
><br>
> Almost everything in it needs special handling.<br>
><br>
>> 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.<br>
>><br>
><br>
> I think you're looking at a multi-year project.<br>
><br>
> John<br>
><br>
<br>
</blockquote></div>