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

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

Re: Gradle bootstrap build with maven

Show all headers | View raw

Le 2025-03-17 21:44, Moritz a écrit :
> 
> 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>

If you made that into a custom Gradle task like I did for 
MakefileMakerTask you could get rid of the parser and the hardcoding in 
SettingsParser, and possibly find ways to minimize the amount of manual 
tweaking afterwards.

> 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.

Having looked at both I think they are both similarly inconvenient to 
review ;) mostly because this is a large project.

The generated PoC Makefile for Gradle 8 is more than 7 MiB and 77k 
lines, but on the other hand it lists exhaustively every single source 
file, jar dependency and intermediate generated file input for every 
task. This is IMO interesting for auditing source code as you can then 
use that as an input to identify unused source files or graph which 
tasks are run for a given source file (I add comments with the original 
gradle task name and dependencies into that Makefile). There is 
certainly some Graphviz potential in there.

Other technical reasons that made me choose a Makefile over other 
possibilities were:
- it's a single file, and it's trivial to keep it out of the upstream 
source tree and relocate it if needed (which is much more convenient for 
packaging)
- it's future-proof: the generated syntax has worked for decades, and is 
extremely unlikely to stop working with future releases of GNU Make 
(which removes a whole source of possible future issues with the 
generator code)
- dependencies are resolved at generation time by Gradle (tweaked by a 
custom plugin and Debian helper libraries) which makes the build fairly 
reproducible; having the dependencies resolved again at build time by a 
different tool (in theory the logic is the same, but the devil is in the 
details) may introduce issues.

> 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.

Unfortunately with their development model that can't be ensured, 
especially on the Gradle side. They don't even try to make a given 
release of Gradle buildable by a previously released version. New major 
releases are commonly built by rc releases, which may be built by 
milestone releases or even nightly builds. I'm pretty sure that Gradle 9 
for example is going to introduce breaking changes that will make it 
impossible to build it with any release of Gradle 8 without downgrading 
or rewriting significant parts of the build scripts, which is not 
trivial. I'm expecting that bootstrapping it again is going to be 
easier.

> 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.

That's 1.3.31 currently. Thank you for reminding me that it's still not 
into testing, I've just closed two resolved FTBFS bugs to see if that 
helps with the migration.

> Gradle also references these dependencies that are built with Gradle 
> (list won't be complete, just the obvious ones):
> 
> * kotlin-stdlib
> * kotlin-reflect
> * kotlin-compiler-embeddable (dependency of 
> 'gradle-declarative-dsl-core', probably the biggest one together with 
> stdlib as it requires a modern bootstrapped kotlin compiler)

These are packaged with kotlin,

> * kotlinx-serialization-core
> * kotlinx-serialization-json

these will be with kotlinx-serialization,

> * org.jetbrains.annotations
> * org.jetbrains.intellij.deps.trove4j

and these are already packaged (libjetbrains-annotations-java and 
libtrove-intellij-java) and appear to be usable to rebuild gradle.

> 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.

native-platform and/or fileevents maybe? That happens sometimes, or they 
forget to push release tags. Messaging them on their Slack usually gets 
the issue quickly resolved.

Cheers,

-- 
Julien Plissonneau Duquène

Back to linux.debian.maint.java | Previous | Next — Previous 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