 | NixOS JVM | 131 Members |
| 28 Servers |
| NixOS JVM | 131 Members |
| 28 Servers |
| Sender | Message | Time |
|---|---|---|
| 16 Aug 2025 | ||
 msgilligan | I've approved this Gradle 9 PR and I'm hoping one of the maintainers can review it: https://github.com/NixOS/nixpkgs/pull/421047 | 16:41:04 |
| msgilligan | ollijh has requested that we bump the default Gradle version to 9 as part of this PR, but to me this seems premature. I would think that the individual package maintainers should update individually and perhaps follow what the upstream packages are doing. And projects that use non-built-in plugins often need to wait for plugins to be updated. I tried bumping three packages selected arbitrarily and none of them worked. See https://github.com/NixOS/nixpkgs/pull/421047#issuecomment-3189716199 | 16:48:31 |
 emily | how long will 8 be in security support? | 16:50:20 |
| msgilligan | Until Gradle 10 ships | 16:56:27 |
| emily | seems fine to ship as the default for 25.11 then | 16:59:20 |
| emily | we still have Gradle 7 though… | 16:59:35 |
| emily | which should not go into 25.11 | 16:59:38 |
| msgilligan | You mean leave Gradle 8 as the default for 25.11? | 17:00:59 |
| msgilligan | Looks like there's been progress on removing gradle_7: https://github.com/NixOS/nixpkgs/issues/358845 (It looks like | 18:57:34 |
| 17 Aug 2025 | ||
 vog | Need more reviewers to fix an issue with fetchMavenArtifact: https://github.com/NixOS/nixpkgs/pull/433975 | 04:14:48 |
| vog | * Need more reviewers to fix an issue of fetchMavenArtifact: https://github.com/NixOS/nixpkgs/pull/433975 | 04:14:58 |
| vog | * Need more reviewers for my PR that fixes an issue of fetchMavenArtifact: https://github.com/NixOS/nixpkgs/pull/433975 | 04:15:45 |
| 18 Aug 2025 | ||
 Tomodachi94 (they/them) | I think somehow searching for Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. in all direct dependents on gradle and then updating those to gradle_8 would be more appropriate | 00:42:36 |
| Tomodachi94 (they/them) | (Didn't someone say somewhere something about searching all Hydra logs is possible? If it is, that would be the best way to figure that out imo) | 00:43:20 |
| Tomodachi94 (they/them) | And we should also be reviewing all of our explicit usages of gradle_8 and updating where appropriate, but that's another tracking issue to be created once 7 is gone | 00:44:23 |
| Tomodachi94 (they/them) | Here's an example of | 00:45:17 |
| Tomodachi94 (they/them) | * Here's an example of me doing this: https://github.com/NixOS/nixpkgs/pull/359177 | 00:45:32 |
| msgilligan | But it sounds like (if I understand emily correctly) there is consensus here (in this room) that we can merge Gradle 9 without changing the default or making changes to any packages that use Gradle. This means initially that use of Gradle 9 will be opt-in. And that we should remove Gradle 7 before 25.11, but Gradle 8 can remain the default for 25.11. Is this a fair summary? | 00:53:03 |
| emily | I think that's fine yes (but I agree w/ Tomodachi94 (they/them) that mass-bumping things early is the best way to avoid the pain of "we have three EOL versions packaged and it's totally unclear whether these packages actually need them". actually, I like not using versioned pins when you don't have to, because then it's clear what actually potentially needs work to bump, when it breaks) | 00:54:13 |
| msgilligan | * But it sounds like (if I understand emily correctly) there is consensus here (in this room) that we can merge Gradle 9 without changing the default or making changes to any packages that use Gradle. This means initially that use of Gradle 9 will (initially) be opt-in. And that we should remove Gradle 7 before 25.11, but Gradle 8 can remain the default for 25.11. Is this a fair summary? | 00:54:29 |
| Tomodachi94 (they/them) | I'm fine with everything except for gradle_8 = gradle; in 25.11. I think we have enough time before the release (3 months) to sort out the breakages that would be caused, especially because it's a simple s/gradle/gradle_8/g in the locations where breakages occur | 00:55:20 |
| Tomodachi94 (they/them) | I'm fine with everything except for gradle_8 = gradle; in 25.11. I think we have enough time before the release (3 months) to sort out the breakages that would be caused, especially because the fix is a simple s/gradle/gradle_8/g in the locations where breakages occur | 00:55:35 |
| msgilligan | Yeah, that's a reasonable position. | 00:56:21 |
| msgilligan | The sensitivity of Gradle builds (and Gradle plugins) to version upgrades is perhaps Gradle's biggest flaw. (It's tied with the sensitivity of Gradle itself to JDK version bumps, but I think that might be betting better.) | 00:57:42 |
| Tomodachi94 (they/them) | (Yes, I am volunteering to help with the Gradle 8 breakages🙂) | 00:57:51 |
| Tomodachi94 (they/them) | But first, we definitely should get rid of Gradle 7 before we start cleaning up 8 usages | 00:58:42 |
| msgilligan | Yeah, getting rid of Gradle 7 is higher priority. Your tracking issue for that is very well-done and very useful! | 00:59:40 |
| msgilligan | Did you see my comment about openjfx 's dependency on gradle_7? | 01:01:22 |
| Tomodachi94 (they/them) | Just now 🙃 That definitely looks to be the case | 01:02:31 |
| Tomodachi94 (they/them) | To start I think I'll mark 7 as insecure and backport that to 25.05 so that there's no expectation of that being secure. (Think I did that with Gradle 6 about half a year ago?) | 01:04:06 |