Feature: Support for generating project-info.json

[charles-dyfis-net]

Upstream nixpkgs contains a buildMaven macro intended to be used with a project-info.json file describing a package's dependencies. The upstream-supported tool for generating this file is NixOS/mvn2nix-maven-plugin; however, this tool has at least one major bug which dwn is not presently prone to.

Would a PR adding support for generating project-info.json files for use by buildMaven be welcome?

[bendlas]

BLUF: not without solid pom.xml support

Incidentally, shortcomings in mvn2nix were one of the motivations, for starting dwn in the first place. Still, slapping that project-info.json exporter into dwn and calling it done would hardly help anybody.

What are the use cases?

• Replacing mvn2nix in a maven-based project?
  • That would entail dwn getting support for pom.xml (including plugins, ...), which would take it 95% towards being a replacement for mvn2nix/buildMaven. I'd rather see the bugs in mvn2nix fixed, maybe sharing components with dwn, than to attempt to replace it.
• Building a clojure project via pom?
  • see first
• Writing a dwn descriptor for a java project?
  • You'll probably be better off using/improving dwn's javac support.
• Reusing the project-info.json format instead of repo.edn in dwn
  • This might be a good idea, if we can manage without breaking anything, but still: What's dwn going to do with a project-info.json generated by mvn2nix (lacking project.nix)?

Any I'm missing?

What bugs in mvn2nix-maven-plugin are affecting you?

[charles-dyfis-net]

So, here's the thing -- I'm not trying to build my own project. I'm not even trying to build Nix derivations, except as an interim step. I'm trying to build packages for a non-Nix distribution in a sandboxed environment managed by Nix.

buildMaven's ability to create a Maven cache directory is exactly what I need, since it can be passed into the build VM and dropped in (or symlinked) to the build user's ~/.m2 for use by the foreign distribution and project's existing build infrastructure.

So I certainly do have an odd use case, no doubt.

[charles-dyfis-net]

As for why I'm not using mvn2nix-maven-plugin, the immediate blocker is NixOS/mvn2nix-maven-plugin#19.

[bendlas]

Sounds perfectly valid. So you don't require the pom.xml reader, because you only want the repository for one or more already packaged coordinates?

That, I could actually see as a standalone command in dwn, because it's the same problem, that I solve during the bootstrapping dance in deps.aether.
Have you seen, how far you get with this?

closureRepoGenerator {
  dependencies = [["group" "dependency" "version"] ...];
}

[charles-dyfis-net]

Rereading after a bit of time (my earlier comments were written on the train), I see your points -- the POM reader is indeed essential for enough cases that there's very limited value without it. Frankly, I like the webnf.dwn.deps.aether codebase -- REPL-friendliness does a lot of good for ease of exploration and experimentation -- but letting that distract me from fixing mvn2nix is indeed perhaps not the wisest choice.

[bendlas]

Glad to hear it, and sorry that dwn doesn't do what you need it to, yet.