@pyrox:pyrox.dev I've updated the PR that introduces the default plugins repo. I've addressed review feedback and added two commits that handle unrelated package build failures. Not sure if that should be separate PRs. I wanted a state where nixpkgs-review passes with out having to wait for other PRs to be merged first.

I've also rebased onto main and ran into an issue with the new maven_4 package that was merged recently: unfortunately they changed completely how default plugin versions are handled inside maven. Previously it was some xml files, which made it easy to extract this data. Now it' constants in Java code which are constructed by concatination of other constants. So there's no easy grep in the java sources solution for maven_4.
I didnt want to blow the scope of the PR, so I decided to add some logic that make maven_4 behave like maven_3 did before: essentially package dependency FOD hashes need to be updated when maven_4 package is updated. I want to address this in a follow up PR.

Link: https://github.com/NixOS/nixpkgs/pull/527061

Folks, https://github.com/NixOS/nixpkgs/pull/527061 is ready to be integrated from my PoV. I fixed the two failing packages and I tested the whole update flow end to end:

• run update script on maven updates maven's src coords as well as the default plugins repo hash.
• rebuilding a downstream package works without recalculating that package's mvnHash.

I'd relly like to get that in so we can focus on the maven version update that was blocked because of many downstream packages breaking with mvnHash missmatches.

Just a quick update on that one 👆 unfortunately (or luckily?) @fliegendewurst:matrix.org pointed out, that the approach I implemented doesn't work. There is a lot of complexity in capturing the project dependencies and separating it from the implicit plugin dependencies. In particular a plugin that is pulled in implicitly via default plugin versions might have a dependency on google guava. So guava needs to be part of the default plugins FOD. But there may be a project thay where that guava version might also be reachable as a direct project dependency. In that case it needs to be part of the project's dependency FOD as well.
Then there is also the complexity of implicit dependencies resolved at runtime that are project dependent. A good example for this is maven-surefire-plugin: it resolves test framework provider jars based on which test framework is on the classpath. The version of the provider depends on the plugin version and the plugin version may not be explicitly defined, so ends up being maven version dependent.
I realize this is a lot to digest, so I might as well write a blog post... 🤔

So anyway, I'm not ready yet to give up on @msgilligan:matrix.org idea, because I think it would be great to have it... So yesterday I started vibe coding a maven extension that writes two dependency manifest files: one for the project dependencies and one for the implicit dependencies as a machine readable json file.
This can be injected into the build, when we capture project dependencies. In order to capture all possible implicit dependencies, I will set up a probe project in nixpkgs, so for each maven release we can run a command to generate the complete closure of implicit dependencies.
Heres the code: https://github.com/britter/nixpkgs-maven-extension

I want to try and see if I can come up with an implementation in nixpkgs thay correctly separates project dependencies from implicit dependencies...

Will keep you posted.