Hi there! Would there be interest in reworking the build logic?
All the procedural Gradle in one large file makes it hard to understand the build logic. It looks very complex. And it may be performing below optimum (this is just a conjecture). I know that the current build is very obviously working. And that there may good reasons to keep it in its current form. (familiarity, ability to do inject additional logic in downstream commercial builds, etc.) But if there is an interest, I would like to make the build more idiomatic Gradle. And when possible, make it fully declarative(1). I do not have a magical solution in the drawer. I would like to see the response to this mail, before I start looking at the problem in earnest. Changing the build would be an explorative and iterative task. And I would need to know if there are some non-obvious out-of-tree features that need special handling. But hopefully it would provide some useful benefits on the way. Even if the final goal is not reached. Up front I expect to do at least: * Move dependencies to catalogs (2). * Move logic into buildSrc to define Tasks and Plugins (in Java). * Use lazy task registration. * Use better task input definitions (3). * Use individual build files in each module. 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. So I suggest that maybe the work be done in separate build files for a start. The new build could be invoked with an extra argument to Gradle. This would make it simple to compare the output of the current and the new build. And to purge the new build if that becomes necessary. Looking forward to your replies! Thanks, Jesper Skov 1: https://blog.gradle.org/declarative-gradle-april-2025-update 2: https://docs.gradle.org/current/userguide/version_catalogs.html#sec:version-catalog-declaration 3: https://bugs.openjdk.org/browse/JDK-8290976
