List all dependencies and more for building a project

[mosabua]

I am looking at toolbox and mima to potentially help me with a task. I would like to create a list of all artifacts needed to build a project from an empty local repo.

So essentially have a list of GAV coordinates that includes:

• all parent poms of the project itself
• all plugins and their needed dependencies including parent poms or whatever else necessary
• all dependencies and their transitive dependencies down and parent poms up the tree

A bonus could be to get the Maven binary from a wrapper config added and whatever it would need at runtime that is not part of the list above. I think that should be nothing but...

Another bonus for later could be taking extensions into account.

Is this something that would be useful for toolbox? Personally I think yes.

In fact I think the plugin-tree does the plugin side of things mostly but maybe its missing parent poms in the tree. gav-tree might also help. Thoughts?

[cstamas]

The parent-child-tree shows external parents as well:

But yes, for proper go-offline support, Toolbox lacks two things: those artifacts "hidden" in plugin config and wrapper, everything else _ (even extensions) is supported_. True, there is no such goal yet. All in all, these are missing:

• artifacts "hidden" in plugin configs
• maven wrapper

[cstamas]

Also, I am personally not a fan of go-offline-like goals (for that above, but also as explained here https://maveniverse.eu/blog/2026/02/03/goal-go-offline-must-go/ ) But I think we can take a stab on it.

IMO, why not just build it? And then if you do that with empty local repo, you end up with everything in it. Or, use Mimir (+ empty local repo), and "just build it", and in that case your Mimir cache is populated (you can rebuild without Maven going remote).

[mosabua]

That was my other approach. I could just build it off a local empty repo, then analyze the repo by walking the whole directory tree and create a list of everything that was downloaded and cached. I want to be able to have a list of all needed artifacts in GAV format and then check another repo to see what is there and what is missing so that I can drive towards everything being there.

Do you think this naive approach is potentially better? It doesnt have to be 100% accurate .. just a good first stab at it

[cstamas]

IF we can exclude snapshot dependencies (external dependencies to reactor; Mimir handles only immutable release artifacts), I'd recommend going Mimir way instead then. Mimir session may collect you all this for you (currently does not).

[mosabua]

Cool.. I will have to look at that next then. Thanks

[adambkaplan]

Mimir definitely looks promising - you can certainly create a software bill of materials by starting with a "clean" state and simply walking its directory tree after a typical build invocation (ex: mvn clean install)

One thing that might be harder to compute with Mimir's file tree is the scope for a given dependency (as far as I can tell). Maven scope data is useful for vulnerability analysis and reporting (ex: VEX document generation). For example, a flaw in a test scoped dependency probably doesn't impact the "consumer" artifact.

[cstamas]

@mosabua @adambkaplan I will try to draft something with Mimir, for example something like a "recipe", basically listing all artifacts asked by Maven to build given thing. Also, I was wrong: mimir does not need your local repo to be empty, it can still collect "all seen" artifacts.

Re scope. Yes, Maven may be thin here, due its internal duality: collecting graph (scopes are known) are one thing, but later resolving is really about flat list of artifacts.... will try to figure out something here.

[cstamas]

So far Mimir can collect this, data needs to be refined, but EVERYTHING Maven resolves is here:
https://docs.google.com/spreadsheets/d/1o6UkHdgZ8q3YyZtuS9HnLTp-QksOT7x_5UPDC_ZEJXY/edit?usp=sharing

apache/maven-deploy-plugin@8cd2345

This is maven-deploy-plugin the maven-3 branch of the plugin.

[cstamas]

A short explanation: the list was sorted and is not in runtime order. Also is made unique (ie slf4j-api is resolved for almost all plugins)

• Lines lacking context; need to look what exactly are those (I suspect surefire?)
• The rest (those w/ context) is pretty clear.
• Those with scope "n/a-node" (no DependencyNode associated) are asked by ModelBuilder, usually during dependency collection (so there is no DependencyNode yet, POM is being parsed still for given node). Also, observe that those are all POM artifacts.
• Those with scope "n/a" are having scope "" (empty string), Is valid for root dependencies (like plugin roots) but NOT for project dependencies.
• Origin is clear (in my case "central" the central repo)