Groups | Search | Server Info | Keyboard shortcuts | Login | Register
Groups > linux.debian.maint.java > #12958
| From | Moritz <mormund@mailbox.org> |
|---|---|
| Newsgroups | linux.debian.maint.java |
| Subject | Re: Gradle bootstrap build with maven |
| Date | 2025-03-17 21:50 +0100 |
| Message-ID | <Krpzj-6Omx-1@gated-at.bofh.it> (permalink) |
| References | <KqTg5-6sCO-7@gated-at.bofh.it> <KrfgB-6HqN-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi Julien, thanks for referencing my repository, hope it helps. > That's an interesting approach. Did you use a generator for the > pom.xml files, and if so how much manual adjustment was required > afterwards? Yes, I built a crude generator for this based on the output from `./gradlew [module]:dependencies --configuration compileClasspath` to get the module dependencies with each other. I think most poms are unchanged from the generated code. I've uploaded the code as a PR here <https://github.com/MorMundHS-MA/gradle-maven-bootstrap/pull/2> > On my side I've started to write a Makefile generator that uses Gradle > itself to generate the recipes. It's not finished (and not functional) > yet, but you can get an idea of what the result would look like there [1]. Using a Gradle plugin for this is smart. I wasn't familiar enough with the ecosystem to attempt that, but with Gradle/Maven plugins you can probably get to a fully automated/reproducible conversion. Not sure if Makefiles will be a good choice, as the project is large with a lot of dependencies between the modules. The generated poms are easily reviewable by a human, I think this will be much harder with Makefiles. But maybe I'm overthinking the supply chain trust issues with bootstrapping build tools. > The generator is the MakefileMaker class at the bottom of [2]. I'm > planning to add custom logic to generate the additional code and > properties at (re)build time. The idea is to have something reasonably > simple that could be used to bootstrap a future version with minimal > or no changes (ideally) to the generation logic. I was hoping that bootstrapping one modern version of Gradle/Kotlin would be enough to build future versions using the tooling itself. But I don't know how commonly they still introduce new functionality/breaking changes that would prevent building with older versions. > They still use Kotlin 2.0.21 currently, setting the source > compatibility to 1.9 (or 1.8 maybe?) to force the use of the legacy K1 > compiler, and adding another legacy dependency as they use APIs that > are now deprecated and even removed for some. It's possible to compile > the Kotlin code using older compilers (with a few minor adjustments > eventually) but the Kotlin scripting integration (DSL) in Gradle is > much less likely to be buildable or work with older versions of Kotlin > compiler libraries without some extensive changes. Which version of Kotlin has been bootstrapped? I think Debian had 1.3 at some point, but I'm not sure if that was completely built from source. At least it isn't available in testing anymore. > So far the only other dependencies I found that will need to be > bootstrapped in the same batch (with gradle and kotlin) are: Gradle also references these dependencies that are built with Gradle (list won't be complete, just the obvious ones): * kotlin-stdlib * kotlin-reflect * kotlinx-serialization-core * kotlinx-serialization-json * kotlin-compiler-embeddable (dependency of 'gradle-declarative-dsl-core', probably the biggest one together with stdlib as it requires a modern bootstrapped kotlin compiler) * org.jetbrains.annotations * org.jetbrains.intellij.deps.trove4j There is also one additional Gradle repository, which I cannot find right now. But I had to downgrade its version manually as the Gradle devs hadn't uploaded their newest version to a public registry yet when I was working on it. But it was also built with Gradle. Best, Moritz On 17.03.2025 10:42, Julien Plissonneau Duquène wrote: > Hi Moritz, > > Le 2025-03-16 11:10, Moritz a écrit : >> >> I got interested in the problem of bootstrapping a modern versions of >> Gradle, mainly due to the old version available in Debian. As far as >> I can tell, efforts have been mostly focused on using older versions >> to bootstrap an up-to-date version. > > Most but not all. My own branch also uses the same version of Gradle > to rebuild itself. > >> I wanted to explore the feasibility and effort required to bootstrap >> with Maven instead. I now have a working purely Maven-based build >> that generates a distribution capable of building Gradle itself. The >> code is available here >> <https://github.com/MorMundHS-MA/gradle-maven-bootstrap>. > > That's an interesting approach. Did you use a generator for the > pom.xml files, and if so how much manual adjustment was required > afterwards? > > On my side I've started to write a Makefile generator that uses Gradle > itself to generate the recipes. It's not finished (and not functional) > yet, but you can get an idea of what the result would look like there > [1]. The generator is the MakefileMaker class at the bottom of [2]. > I'm planning to add custom logic to generate the additional code and > properties at (re)build time. The idea is to have something reasonably > simple that could be used to bootstrap a future version with minimal > or no changes (ideally) to the generation logic. > >> While it was fun, I am not sure how much this actually helps as it >> still requires a pre-build Kotlin compiler (at least 1.8 I think, >> even though >2.0 is used). Additionally some of the other >> dependencies are also built with Gradle and would have to be >> bootstrapped as well. But I wanted to share my progress so far non >> the less. > > They still use Kotlin 2.0.21 currently, setting the source > compatibility to 1.9 (or 1.8 maybe?) to force the use of the legacy K1 > compiler, and adding another legacy dependency as they use APIs that > are now deprecated and even removed for some. It's possible to compile > the Kotlin code using older compilers (with a few minor adjustments > eventually) but the Kotlin scripting integration (DSL) in Gradle is > much less likely to be buildable or work with older versions of Kotlin > compiler libraries without some extensive changes. > > So far the only other dependencies I found that will need to be > bootstrapped in the same batch (with gradle and kotlin) are: > - kotlinx.serialization > - kotlinx-metadata-jvm 0.5.0 (Kotlin 1.8.10 is the last release with > that version). > > Thank you for sharing this. I will add a link to your repository on my > own wip/README. > > Cheers, > > > [1]: > https://salsa.debian.org/jpd/gradle/-/blob/478abafcd391cc28549f9b369d7b42a3febb3197/debian/gradle.Makefile > [2]: > https://salsa.debian.org/jpd/gradle/-/blob/478abafcd391cc28549f9b369d7b42a3febb3197/debian/init.d/gradlebuild/DebianGradleBuildPlugin.gradle#L638 >
Back to linux.debian.maint.java | Previous | Next — Previous in thread | Next in thread | Find similar
Gradle bootstrap build with maven Moritz <mormund@mailbox.org> - 2025-03-16 11:20 +0100
Re: Gradle bootstrap build with maven Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-03-17 10:50 +0100
Re: Gradle bootstrap build with maven Moritz <mormund@mailbox.org> - 2025-03-17 21:50 +0100
Re: Gradle bootstrap build with maven Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-03-18 10:30 +0100
csiph-web