This is to let you know that I am currently working on overhauling and upgrading the gradle package to the upcoming 8.11 release. This is
indeed quite challenging and I am not yet to the point where I could
share a repo and let others experiment and contribute, but I hope to get there in a few days or maybe next week, I will then post an update with
a link.
This is to let you know that I am currently working on overhauling and upgrading the gradle package to the upcoming 8.11 release. This is indeed
However, I would suggest to make a "gradle8" package
that could be installed in parallel with the existing Gradle.
after finding lots of .class files in the "source" repository and
getting the impression that some bits might be missing.
This is to let you know that I am currently working on overhauling and upgrading the gradle package to the upcoming 8.11 release. This is
indeed quite challenging and I am not yet to the point where I could
share a repo and let others experiment and contribute, but I hope to get there in a few days or maybe next week, I will then post an update with
a link.
My current plan is to make it at least a 2-stage build as there is no
point in trying to make its complicated buildscript work with the
currently packaged version 4.4.1. I don't know yet if the versions of
Groovy and Kotlin currently in Debian will work with these builds but I
will try.
I am also factoring in the gradle-debian-helper in the build
of Gradle itself to use its logic to resolve artifact versions, even
though the plugin can no longer be used as is because it depends on a
core 'maven' plugin that disappeared with Gradle 7.
About myself, I haven't contributed much to the project yet but I am a
long time FLOSS advocate and Debian user, with some background in large
scale deployments, SRE and DevOps things. I didn't have much prior
experience with Gradle until the past few days, so I am learning while
doing it.
Kotlin and Gradle are tightly coupled, and unless you are ready to
rewrite their build systems with something else and replace the Kotlin
code in Gradle, I don't think it's possible to bootstrap them separately.
That was the motivation behind the gradle-bootstrap package currently in
sid: start with a binary only package containing Gradle, Koltin and
their dependencies, and use it to gradually rebuild these components
from source until the bootstrap package is no longer needed. I haven't
pushed further in this direction by lack of time but I still think
that's the best strategy to build a recent version of Gradle and Kotlin.
Note that there is also an issue with the Gradle enterprise plugin that
isn't open sourced and has to be removed. I don't know if Gradle 8 is
still affected.
maybe next week
getting the impression that some bits might be missing.
Hi Julien,
Le 04/11/2024 à 14:43, Julien Plissonneau Duquène a écrit :
This is to let you know that I am currently working on overhauling and
upgrading the gradle package to the upcoming 8.11 release. This is indeed
quite challenging and I am not yet to the point where I could share a repo and
let others experiment and contribute, but I hope to get there in a few days or
maybe next week, I will then post an update with a link.
Thank you for tackling this issue, this challenge requires a lot of time, skills
and patience. It's long, thankless, but definitely fun if you are a bit masochistic.
My current plan is to make it at least a 2-stage build as there is no point in
trying to make its complicated buildscript work with the currently packaged >> version 4.4.1. I don't know yet if the versions of Groovy and Kotlin currently
in Debian will work with these builds but I will try.
No they won't work. Getting Kotlin 1.3.31 to build with Java 17 was an epic achievement but unfortunately it didn't even allow us to package an incremental
update of Gradle.
Kotlin and Gradle are tightly coupled, and unless you are ready to rewrite their
build systems with something else and replace the Kotlin code in Gradle, I don't
think it's possible to bootstrap them separately.
That was the motivation behind the gradle-bootstrap package currently in sid: start with a binary only package containing Gradle, Koltin and their dependencies, and use it to gradually rebuild these components from source until
the bootstrap package is no longer needed. I haven't pushed further in this direction by lack of time but I still think that's the best strategy to build a
recent version of Gradle and Kotlin.
Note that there is also an issue with the Gradle enterprise plugin that isn't open sourced and has to be removed. I don't know if Gradle 8 is still affected.
Another thing I can offer is help with funding for doing this work, if
that is interesting to you. Specifically, NLnet's Mobifree fund (https://nlnet.nl/mobifree/) is likely to fund this kind of work
because Gradle is so important for Android. And having Gradle in
Debian means it truly is free software. I will happily help you put
together a proposal for NLnet. The money would then go directly to
you. They pay you as a gift from a foundation, and the overall process
is relatively easy.
I discarded the idea to upgrade Gradle to 6.x or even newer releases
because
the main problem with Gradle for Debian is the complex interaction
between its
(build)-dependencies. Since we only support one version of a library in general, you will quickly reach a point where you are stuck in a loop
between
upgrading existing Debian packages, then fixing broken
reverse-dependencies,
and then moving on to build Gradle offline. And for me those iterations
never
seemed to end.
My last idea was to only make a small step forward and upgrade Gradle
to 4.6,
the first version that uses Kotlin. I downloaded the official binary
release of
4.6 and installed it to /opt/gradle/gradle-4.6. I managed to
successfully build
gradle 4.6 offline with Debian packages but only with the official
binary
release. If I replace this one with the resulting Debian package and
try to
rebuild Gradle, the build fails.
I discarded the idea to upgrade Gradle to 6.x or even newer releases because the main problem with Gradle for Debian is the complex interaction between its
(build)-dependencies. Since we only support one version of a library in general, you will quickly reach a point where you are stuck in a loop between upgrading existing Debian packages, then fixing broken reverse-dependencies, and then moving on to build Gradle offline. And for me those iterations never seemed to end.
Both Gradle and Kotlin are moving targets indeed, and they were moving
even faster around these releases according to their respective
histories, which probably explains why you (and nobody else as a fact) weren't able to catch up: it might well have been simply impossible at
that stage.
Maybe jumping to recent and stable Gradle/Kotlin releases would be
easier, but does that even exist? Is there a couple a Gradle and Kotlin releases that can be used to build each other (and themself).
By the way, any opinion about making that new gradle a "gradle8" package
that provides "gradle"?
My feeling is that maintaining up to 3 major versions of Gradle is
probably going to be necessary, given the breaking changes with every
major release (and sometimes in between) and what's already announced
for future releases.
I'm not a big fan of potentially long lived experimental packages as it
makes updates in sid more complicated. For example let's say the
package foo has the version 1.0 in sid/testing and the version 3.0 in experimental, the upstream and pristine-tar branch on salsa are updated
to the 3.0 release. If I want to update the sid package to 2.0, I can't import the release without rebasing/reimporting the experimental 3.0
release on these branches.
Or maybe we can keep all of them in experimental for a while, and
duplicate only those that prove (or are suspected eventually, after discussing that) to be problematic? I would rather keep things as straightforward as possible with the dependencies, gradle has a lot of dependencies but several of them only have very few reverse-dependencies other than gradle and sometimes kotlin.
By the way, any opinion about making that new gradle a "gradle8" package
that provides "gradle"? My feeling is that maintaining up to 3 major
versions of Gradle is probably going to be necessary, given the breaking changes with every major release (and sometimes in between) and what's already announced for future releases.
Markus raises a good point, I would add that if there is a risk at some
point of breaking the existing packages after upgrading a dependency,
then introducing a new package for the updated dependency is the way to
go. We can deduplicate the dependencies later when the transition to
the newer Gradle is complete.
[...]
I would not follow that path today for Gradle unless working on a theoretical bootstrap. That would still be a difficult work, maybe even
more difficult than the current releases, and the result would still be
a severely outdated Gradle, just a little bit less outdated, and with
still a lot of work ahead to bring it to current releases.
But I wouldn't rule out a similar path for Kotlin yet as we may well
lack alternatives for that one...
I remember that upstream confirmed they only use nightly builds to
build gradle
and don't promise that any later version may be able to build an older version.
Jumping directly to gradle 8 would be perfect of course.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 00:30:39 |
| Calls: | 12,097 |
| Calls today: | 5 |
| Files: | 15,003 |
| Messages: | 6,517,858 |