You mean something like this? https://gist.github.com/cstamas/3f437e46271986e2e10a9a54f718799c
T On Fri, 19 Jun 2026 at 17:52, Romain Manni-Bucau <[email protected]> wrote: > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
