Groups | Search | Server Info | Keyboard shortcuts | Login | Register


Groups > linux.debian.maint.java > #12958

Re: Gradle bootstrap build with maven

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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