| 16 Aug 2025 |
 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 openjfx wasn't on the list. It looks like removing gradle_7 might mean no openjfx prior to 23, leaving only jfx 25 as a supported version. Apps can always pull the version of jfx they need from Maven Central, I suppose. I'm not sure how this will affect building JDKs with bundled jfx.)
| 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 |
| 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 on stable. (Think I did that with Gradle 6 about half a year ago?) | 01:04:17 |
| msgilligan | That sounds like a good start. Please ask me to review that PR because I'm curious to see how that is done. | 01:04:52 |
| Tomodachi94 (they/them) | An aside: I think you'd make a wonderful addition to the Java team if you're interested in joining. You seem very invested in the Java ecosystem in Nixpkgs, and you're very keen on helping out | 01:06:49 |
| emily | only old ones IIRC | 01:07:47 |
| emily | openjfx23 should be fine | 01:07:50 |
