There is actually a deeper problem here, which is that if authenticated is not set, then mvn2nix doesn't know what remote repository the dependency belongs to.

Not sure I follow ... authenticated is written out by mvn2nix, right? Do you mean that buildMaven doesn't know what repo the dep belongs to?

Not sure I follow ... authenticated is written out by mvn2nix, right?

mvn2nix writes authenticated for each dependency from a remote repository, at the same time as it writes the other information for that remote repository (such as URL). For local dependencies, mvn2nix does not write authenticated or any remote repository information because that information isn't available. Unfortunately, maven sometimes incorrectly reports remote dependencies as local dependencies (*). If authenticated is missing, that is usually the reason. Nix cannot fetch the dependency because mvn2nix thinks it is locally available, and so the builder will fail due to the missing dependency.

TL;DR: this pull request fixes evaluation, but not the build.

(*) For our purposes, the main reason maven reports remote dependencies as local dependencies is if they are cached locally. I consider this a serious flaw; caching should be transparent!

Ah, okay, gotcha -- that makes sense, thanks for figuring it out. (And I agree it's a serious flaw in Maven!)

So in some sense it's yet another reason to use the -Dmaven.repo.local=$(mktemp -d -t maven) work-around proposed at NixOS/mvn2nix-maven-plugin#5, I guess?

FWIW, I'm still not entirely convinced that a maven plugin is the right way to figure out the complete set of maven dependencies for a project, at least not without some upstream work on maven itself. See discussion at #19741.

Maybe it's worth a post to the maven dev team's mailing list to try to figure some of this out with their help? Even something general like "hey, what would it take to get maven to produce a lock file like npm can?" ...

So in some sense it's yet another reason to use the -Dmaven.repo.local=$(mktemp -d -t maven) work-around proposed at NixOS/mvn2nix-maven-plugin#5, I guess?

Does it work for you though? I've just tried it on the K repo and it didn't.

I haven't tried it, no. :-/

Does it work for you though? I've just tried it on the K repo and it didn't.

It does not, because of NixOS/mvn2nix-maven-plugin#15.

I fixed that, and it still does not work because maven will always resolve the mvn2nix dependencies before it runs the tool. There will always ALWAYS be cached dependencies that mvn2nix will miss if your package has transitive dependencies in common with mvn2nix.

I think the only way forward is to fetch the dependencies through maven itself. I am working on that now. I am still having problems because the K pom.xml file doesn't actually list all its dependencies, but that is a much simpler problem!

@ttuegel are you using dependency:go-offline? Or what other approach are you exploring?

There are 2 existing attempts using dependency:go-offline:

• Maven builds are not documented in nixpgs manual  #19741 (comment)
• https://github.com/icetan/mavenix

Sorry for the confusion -- my script in #19741 is meant for after running a regular build, not dependency:go-offline. My experience was that go-offline didn't always download everything you really needed, only an actual build would do that. I've updated over there to reflect that.

My experience was that go-offline didn't always download everything you really needed, only an actual build would do that.

Yes, I found that. However, a newer version of maven-dependency-plugin seems to do a good enough job with resolve-plugins and go-offline that I can fix 95% of the problem by adding some dependencies that (admittedly) weren't specified in the pom.xml file anyway. I still can't get everything though.

@ttuegel Is your work-in-progress available somewhere?