Debian-Java 2025 wishlists

2024-12-17 Thread sre4ever
Hi, As we are now in the heart of the wishlist season, I would like to proceed with a little experiment and collect your wishes for the Java and JVM ecosystems in Debian next year. Just post what you can think about as a reply to this message, regardless of other proposals (don't worry about

gradle: FI -- reverse dependencies that FTBFS

2024-12-17 Thread sre4ever
Hi, For information: Yesterday I tried to rebuild (on trixie) the 110 identified source packages that depend on Gradle. That kept my low-end, second-hand laptop busy for about 5 hours. Most packages (102, ~93%) were rebuilt without issues. The 8 packages that failed to build OOTB were: 1. a

Re: gradle reboot -- 2024W49 update

2024-12-14 Thread sre4ever
Le 2024-12-14 10:48, Matthias Klose a écrit : what about having two sets of packages? one set encapsulating the bootstrap, which always stays in unstable, and one "production" set, which then migrates to testing? Would that be better to keep the bootstrap knowledge up to date? That's a poss

Re: gradle reboot -- 2024W50 update

2024-12-13 Thread sre4ever
Good evening, Here is a quick report about the (little) progress made this week. Le 2024-12-09 12:08, sre4e...@free.fr a écrit : Now the build fails on Kotlin issues. And now I'm stuck on the (re)build of Kotlin 1.3.31 that currently FTBFS [1]. I will see this week how far I can go with t

Re: gradle reboot -- 2024W49 update

2024-12-10 Thread sre4ever
Le 2024-12-09 19:17, Hans-Christoph Steiner a écrit : I think it would be fine to keep in place, as long as the workflow is documented, e.g. the bootstrapping is not required to be maintained, but it would be nice to have. It's probably not as complicated to maintain as it may look right now,

Re: gradle reboot -- 2024W49 update

2024-12-09 Thread sre4ever
Le 2024-12-09 14:32, Emmanuel Bourg a écrit : I don't think we should try too hard to keep the bootstrapping logic in the package, that'll most certainly be tedious to maintain over time. Well that's indeed something to think about, and I am a bit worried about that as well. With Gradle, the

Re: gradle reboot -- 2024W49 update

2024-12-09 Thread sre4ever
Good day, Some news about the ongoing work on Gradle packaging: Le 2024-12-02 19:43, sre4e...@free.fr 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

Re: gradle reboot -- 2024W48 update

2024-12-02 Thread sre4ever
Good evening, Le 2024-11-22 18:25, sre4e...@free.fr a écrit : Next week I will start working on a detailed action plan and PoC for the rebootstrap, in between build runs and fixups. Updating and then fixing the builds of various packages (not all of them direct dependencies of Gradle) kept me

Re: gradle reboot

2024-11-30 Thread sre4ever
Hi, Le 2024-11-30 09:40, Markus Koschany a écrit : I remember that upstream confirmed they only use nightly builds to build gradle Actually it's a bit more subtle than that: out of curiosity I extracted the last 200 versions used to build Gradle [1], and it appears to be a combination of r

Re: gradle reboot

2024-11-29 Thread sre4ever
Le 2024-11-29 12:49, Emmanuel Bourg a écrit : 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-

Re: gradle reboot

2024-11-29 Thread sre4ever
Le 2024-11-29 11:58, Emmanuel Bourg a écrit : 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). I haven't checked Kotlin yet, but recent relea

Re: gradle reboot

2024-11-29 Thread sre4ever
Hi Emmanuel, Le 2024-11-29 11:42, Emmanuel Bourg a écrit : 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 deduplic

Re: gradle reboot

2024-11-27 Thread sre4ever
Hi Hans-Cristoph, Le 2024-11-26 13:37, Hans-Christoph Steiner a écrit : 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

Re: gradle reboot

2024-11-27 Thread sre4ever
Hi Markus, Thanks for the link to your repo, I will take a look. Le 2024-11-26 14:09, Markus Koschany a écrit : 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. Si

Re: gradle reboot -- 2024W47 update

2024-11-22 Thread sre4ever
Good evening, Some news from this adventure: Le 2024-11-19 11:04, sre4e...@free.fr a écrit : There is currently a regression compared to two weeks ago as I'm currently unable to get the build to start compiling the project, it hangs in a configuration stage. Currently investigating why I fou

Re: gradle reboot

2024-11-19 Thread sre4ever
Good morning, Le 2024-11-04 16:53, Toni Mueller a écrit : getting the impression that some bits might be missing. Well you were right, there are many missing files [1] in the distribution ZIPs, mostly documentation and testing though. I reported that and got no reaction so far. I've updated