| 23 Nov 2024 |
Tomodachi94 (they/them) | * I'm also wondering if we should pin the built-in Maven plugins to versions in Nixpkgs and update them one-by-one instead of with the Maven package. Essentially, introducing a patcher that pins plugins to predetermined versions if they are present in pom.xml, updating them one-by-one after a Maven update is merged | 18:23:37 |
Tomodachi94 (they/them) | We would absolutely need to script those updates though | 18:24:41 |
Tomodachi94 (they/them) | * I'm also wondering if we should pin the built-in Maven plugins to versions in Nixpkgs and update them one-by-one instead of with the Maven package. Essentially, introducing a patcher that pins plugins to predetermined versions if they are present in pom.xml but not pinned, updating them one-by-one after a Maven update is merged | 18:26:16 |
Morgan (@numinit) | I've gotta figure out a way to automatically build gradle.lock with gradle2nix and the sandbox off | 18:33:24 |
Morgan (@numinit) | Since gradle feels the need to resolve dependencies lazily, you basically need to run the build before you can run the build 😩 | 18:34:29 |
Tomodachi94 (they/them) | (Everything would be so much simpler if these build systems just used proper lockfiles 💔) | 18:35:14 |
Morgan (@numinit) | I tried gradle's lock format and it wasn't proper by any extent, lol. No hashes, no URLs | 18:35:37 |
emily | we have a Gradle locking solution in the tree with mitm-cache now | 18:36:09 |
emily | it does just build everything twice though | 18:36:17 |
Morgan (@numinit) | Oh, cool, I was wondering about that | 18:36:22 |
emily | it's awful. all Java tooling is so awful | 18:36:36 |
emily | we really ought to just shim in our own local FS repository and build everything from source but 🙃 | 18:36:59 |
Tomodachi94 (they/them) | Tangentially related: I'm wondering if we should split out the Gradle hook into gradle.hook as well? | 18:37:53 |
Tomodachi94 (they/them) | Anyways I'm going to attempt to refactor the Maven build story to use hooks | 18:39:32 |
Morgan (@numinit) | The setup hooks in gradle2nix work pretty well | 18:39:46 |
Morgan (@numinit) | It's a nice paradigm | 18:39:57 |
Tomodachi94 (they/them) | Wondering if we should rip out mvn2nix Nixpkgs support and send it upstream? | 18:41:01 |
Tomodachi94 (they/them) | Wait the upstream repo is archived: https://github.com/NixOS/mvn2nix-maven-plugin | 18:41:28 |
emily | probably it was merged in to the monorepo | 18:42:21 |
Tomodachi94 (they/them) | Looks like it was semi-automatic: https://github.com/NixOS/mvn2nix-maven-plugin/issues/33 | 18:43:07 |
Tomodachi94 (they/them) | Is anyone interested in reviving it? 🙃 | 18:52:33 |
Tomodachi94 (they/them) | I'm leaning towards ripping it out of Nixpkgs, if anyone wants to revive it they can take the docs and builder and put it into the repository | 18:53:24 |
Tomodachi94 (they/them) | * I'm leaning towards ripping it out of Nixpkgs, if anyone wants to revive it they can take the docs and builder and put it into the repository itself | 18:53:31 |
Tomodachi94 (they/them) | In reply to@tomodachi94:matrix.org Is anyone interested in reviving it? 🙃 We should probably:
Post a call for maintainers on Discourse Wait a week If nobody responds, rip it out as mentioned above If someone responds, collaborate on moving the builder and docs to the upstream repo | 18:55:38 |
Tomodachi94 (they/them) | Nothing in-tree is using it afaict | 18:56:03 |
Tomodachi94 (they/them) | cc @fzakaria, who appears to have been heavily involved in it | 18:56:17 |
| tricktron joined the room. | 19:11:04 |
Tomodachi94 (they/them) | Welcome :) | 19:13:22 |
tricktron | Hello fellow JVM Nixers :) | 19:14:05 |
Tomodachi94 (they/them) | In reply to@tricktron:matrix.org Hello fellow JVM Nixers :) There's a little bit of (unrelated) Maven discussion about mvn2nix if you're interested 🙂 | 19:16:33 |