Le ven. 19 juin 2026 à 18:04, Tamás Cservenák <[email protected]> a écrit :
> You mean something like this? > https://gist.github.com/cstamas/3f437e46271986e2e10a9a54f718799c Almost yes, the differences I'd see/like: 1. do it with repo cache (no custom local repo), all trakcing in mem not files 2. report on demand (a goal can be neat even if it needs an extension to register the tracking at the beginning of the session) 3. (very neat) not just handle resolver resolution but also plugin specifities, can need a new maven 4 API for plugins to give hints about that but would make the report complete and not just partials (this is not possible only from the resolver I think and often plugins use something else than maven shared archivers so hard to instrument) > > > 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] > >
