Re: gradle reboot -- 2024W49 update

Good day,

Some news about the ongoing work on Gradle packaging:

Le 2024-12-02 19:43, [email protected] a écrit :
> The build progressed a bit and now fails on the outdated Groovy

Last week the build progressed some more and now (using --continue) 
generates 78 of the 83 (86 minus 3 dropped) jars that are expected in 
the binary distribution (that's almost 94%). Some Groovy issues were 
solved by copypasting some newer Groovy source code right into the 
project; that's indeed temporary and only necessary until Groovy gets 
updated, and I plan to take care of that right after Gradle.

Now the build fails on Kotlin issues. These are going to be tougher 
(getting it to build is one thing, getting it to actually work is 
another thing) and my current plan to try to use the version that is 
currently in Debian is likely to be a dead end for reasons already 
stated on this list. I already had to drop the new declarative DSL as it 
is not (yet?) needed for rebuilding Gradle (I didn't check for Kotlin 
though) and makes use of many new features that were possibly added to 
Kotlin as part of the collaboration between Gradle and JetBrains. What 
remain are the regular kotlin-dsl and some parts of core-configuration 
written in Kotlin, which are all necessary for core features and 
rebuilding both Gradle and Kotlin.

I will see this week how far I can go with this plan. The alternative 
would be to upgrade Kotlin at the same time, with similar (but a bit 
more complicated) bootstrapping techniques.

Which brings us to the crucial subject of bootstrapping: I now have a 
(non-functional) PoC of how I plan to proceed, which is basically to 
make it possible to rebuild Gradle with a plain old Makefile [1], 
automatically generated from Gradle build scripts, to be updated with 
every new release and committed to the repository as part of the 
packaging sources. For the rebootstrap this would go as follows 
(assuming that all issues that would prevent Gradle from working are 
already resolved):
- maintainer uses a binary distribution of Gradle from upstream to build 
a first-stage patched Gradle and to generate the Makefile; that build 
will not be used and is only necessary to correctly generate the 
Makefile
- maintainer rebuilds a first stage patched Gradle using the Makefile
- maintainer builds a second stage patched Gradle using the 
Makefile-built Gradle, check that it works (test suites), check that it 
generates the same Makefile as the binary distribution, eventually 
checks and investigates for differences in binaries against the 
first-stage build with binary distribution
- maintainer commits packaging updates
- for the CI (or anybody else after the package is published) to rebuild 
the package, debian/rules checks the version of Gradle that is currently 
installed on the system; if the version is not known (i.e. successfully 
tested) to be compatible (and this is probably going to be a very 
restricted set of versions close to the one being built), d/rules will 
build a first-stage Gradle using the pre-generated Makefile, then 
(re)build the target Gradle using a temporary installation of the 
first-stage Gradle.

As usual, comments and contributions are very welcome.

Cheers,


[1]: 
https://salsa.debian.org/jpd/gradle/-/blob/upgrade-to-8.11.1-wip/debian/gradle.Makefile
      — this Makefile is not useable as is, but you get the idea