Hi, One thing I always stumbled upon was how to track where a dependency comes from. We likely all use dependency plugin as a default (toolbox for aventurous/edge ones ;)) but this doesn't give much information, the only source of truth is something between the build pipeline (chain of plugins) and packager plugins.
Just to give an example war plugin can include/exclude deps, add deps using overlay or alike etc... so dependency plugin (toolbox) doesn't cover it as needed for a human being (or an AI). Now think tomee which does handle a full server packaging, server libs, javaagent, bootstrap libs, multiple apps, etc... it is worse. So being able to run something along the line: mvn -Dresolver.track.output=target/myarchive.war#WEB-INF/lib/foo-1.2.3.jar package resolver:report-tracked-paths or alike to say "it comes from this artifact with this resolution path and conflicts resolution would be insanely more accurate and efficient IMHO (even if I agree with habits you know how to do it but you need to have seen multiple issues before). Maybe that's something to give a try to solve, technically we have all we need except the tracking impl/report AFAIK. Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le ven. 19 juin 2026 à 17:34, hitesh sai <[email protected]> a écrit : > Hi Tamás, Maarten, and Gary, > > Thank you for the examples and guidance. After looking through > toolbox:tree, > tree-find, and the Resolver documentation, I understand the problem space > much better now. > > My initial idea was focused on finding why a dependency is present, but I > see that much of this is already covered by existing tools. > > The more interesting gap seems to be explaining Maven's resolution > decisions: > > - Why was this version selected? > - Which dependency management/BOM influenced it? > - Which competing versions were considered but not selected? > - Which mediation rule led to the final result? > > From the Resolver documentation, it seems this information already exists > during the collect/transform phases. The challenge would be exposing it in > a way that helps users understand *why* Maven reached a result, rather than > only showing the final dependency graph. > > I am not attached to the original `dependency:insight` idea if there is a > better direction. I would like to explore something that provides real > value to Maven users and fits the project's needs. > > If there are other related areas you think would be more valuable to > investigate, I would be happy to explore them as well. > > Thanks again for the guidance. > > Best regards, > Hitesh >
