There's also good new Toolbox: https://gist.github.com/cstamas/164369b58490c1bafd8a826d33d07dd2
The goal of tree-find is exactly this, and as gist shows, works with "proper" tree but also verbose tree. Thanks T On Thu, 18 Jun 2026 at 21:56, Gary Gregory <[email protected]> wrote: > > There's also good old 'mvn dependency:tree' > > Gary > > On Thu, Jun 18, 2026, 15:52 Maarten Mulders <[email protected]> wrote: > > > Hi Hitesh, > > > > Unfortunately, I don't know much about Gradle's dependencyInsight task. > > > > Looking at what help:effective-pom does, I think it already answers the > > following questions: > > > > - Why is artifact X present on the classpath? > > - Which dependency path introduced it? > > > > And MPH-183 aims to add the answer to this question: > > > > - Did dependency management or a BOM influence the final selection? > > > > That leaves the following questions still unanswered: > > > > - Which version of the mediation rules was applied? > > - Were alternative versions considered and omitted? > > > > Personally, I think that could be useful information. I find it hard, > > however, to judge if this should go in the Maven Dependency Plugin (as > > you proposed) or in the Maven Help Plugin, as that's where other > > "explanation" of the (effective) POM is reported. **Maybe other > > committers have can share their thoughts on that?** > > > > I'm not sure about Mavens participation in past editions of GSoC. I do > > recall we had proposals earlier this year, but I'm not sure someone from > > the Maven community stepped up to mentor those candidates. > > > > Thanks, > > > > > > Maarten > > > > On 18/06/2026 08:58, Hitesh Sai wrote: > > > Hi Maarten, > > > > > > Thank you for the references. > > > > > > After reviewing dependency:tree and MPH-183 more closely, I think my > > > proposal may be solving a related but slightly different problem. > > > > > > MPH-183 focuses on improving provenance information in help:effective- > > > pom -Dverbose, particularly for dependencyManagement entries imported > > > through BOM chains. > > > > > > The goal I had in mind is closer to Gradle's dependencyInsight task. > > > Rather than answering "Where did this managed version come from?," it > > > would answer questions such as: > > > > > > - Why is artifact X present on the classpath? > > > - Which dependency path introduced it? > > > - Which version of the mediation rules was applied? > > > - Were alternative versions considered and omitted? > > > - Did dependency management or a BOM influence the final selection? > > > > > > For example, dependency:tree can already show paths to a dependency, but > > > it does not provide a focused explanation of why a particular version > > > was selected. > > > > > > Before investing more effort into the proposal, I would appreciate your > > > opinion on whether this distinction is meaningful from a Maven > > > perspective, or whether you feel the existing work around MPH-183 would > > > already address most of these use cases. > > > > > > I also had a more general question regarding Maven and GSoC. While > > > reviewing the recent GSoC idea lists, I noticed that I could not find > > > Maven-specific project ideas. Has Maven participated in GSoC in the > > > past, or is Maven typically not part of the program? I'm curious about > > > the history here, as I'd like to understand whether proposal ideas are > > > usually developed independently by contributors or if there is a > > > different process for identifying suitable GSoC projects within the > > > Maven community. > > > > > > Thanks again for the feedback and pointers. > > > > > > Best regards, > > > Hitesh Sai > > > > > > On Thu, 18 Jun 2026 at 12:05, hitesh sai <[email protected] > > > <mailto:[email protected]>> wrote: > > > > > > Hi Maarten, > > > > > > Thank you for the feedback and for taking the time to review the > > > proposal. > > > > > > I'll take a closer look at the existing `dependency:tree` > > > functionality, especially with the includes parameter applied, as > > > well as the older GitHub proposal you referenced. After reviewing > > > both, I'll compare them against my idea and identify any gaps or > > > differences that could justify a separate feature. > > > > > > I appreciate the guidance and will follow up with a more detailed > > > analysis. > > > > > > Thanks again, > > > Hitesh Sai > > > > > > On Thu, 18 Jun 2026 at 11:56, Maarten Mulders <[email protected] > > > <mailto:[email protected]>> wrote: > > > > > > Hi Hitesh, > > > > > > Great to hear you're interested in contributing to Apache Maven > > > through > > > GSoC! > > > > > > > > > About your proposal: the output you suggest looks quite like > > > that of > > > dependency:tree [1], especially with the includes parameter > > > applied. > > > Could you please highlight where your proposal differs from > > > existing > > > functionality? Also, there is an existing (old, but still > > relevant) > > > proposal on GitHub [3] that maybe relates to what you're trying > > to > > > achieve. I'm not 100% sure, but it might be good to check that > > > one, too. > > > > > > > > > Please note that this reply does not promise I would be > > > available as a > > > mentoring committer. At this point, I'm trying to help you write > > a > > > relevant proposal for GSoC. > > > > > > > > > Good luck, > > > > > > > > > Maarten > > > > > > > > > [1] > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > usage.html#dependency.3Atree <https://maven.apache.org/plugins/ > > > maven-dependency-plugin/usage.html#dependency.3Atree> > > > [2] https://maven.apache.org/plugins/maven-dependency-plugin/ > > > tree-mojo.html <https://maven.apache.org/plugins/maven- > > > dependency-plugin/tree-mojo.html> > > > [3] https://github.com/apache/maven-help-plugin/issues/303 > > > <https://github.com/apache/maven-help-plugin/issues/303> > > > > > > On 18/06/2026 06:35, Hitesh Sai wrote: > > > > Hi everyone, > > > > > > > > I'm Hitesh, a CS student planning to apply for GSoC 2027 with > > > Apache Maven. > > > > I wanted to share my proposal idea early and get community > > > input before > > > > writing the full application. > > > > > > > > The proposal: add a dependency:insight goal to the maven- > > > dependency-plugin > > > > that answers the question "Why is artifact X on my classpath?" > > > > > > > > Current situation: > > > > Users run `mvn dependency:tree` and manually scan hundreds > > > of lines to > > > > find a transitive dependency's origin. There is no direct > > > command for this. > > > > > > > > Proposed solution: > > > > $ mvn dependency:insight -Dartifact=guava > > > > > > > > guava:32.1-jre (declared: 32.0, overridden by spring- > > > boot-dependencies) > > > > └─ spring-context:6.1.2 > > > > └─ spring-core:6.1.2 > > > > └─ com.example:my-app (root) > > > > > > > > Implementation approach: > > > > - Hook into the existing DependencyCollector/ > > > DependencyNode graph, > > > > already built during the resolve phase > > > > - Perform a reverse BFS from the target artifact node back > > > to the root > > > > - Surface version mediation info from > > > DefaultDependencyCollector when the > > > > resolved version differs from the declared one > > > > - Output both text and, optionally, a machine-readable > > format > > > > > > > > Gradle's `dependencyInsight` task already solves this for > > > Gradle users — > > > > this proposal brings equivalent clarity to the Maven > > > ecosystem. I am not > > > > proposing to change any resolution logic, only to expose what > > > Maven already > > > > computes internally in a more accessible form. > > > > > > > > I checked the GSoC 2025 and 2026 idea lists and found no > > > existing Maven > > > > proposals, so I believe this is new ground. > > > > > > > > I'd appreciate: > > > > 1. Feedback on the scope — too big, too small, or about > > > right for 12 > > > > weeks? > > > > 2. Whether a Maven committer would be willing to mentor > > this > > > > 3. Any prior discussion or JIRA tickets I should be aware > > of > > > > > > > > Thank you for reading. Happy to answer questions or share a > > > draft write-up. > > > > > > > > Best regards, > > > > B.V. Hitesh Sai > > > > https://github.com/Hiteshsai007 < > > https://github.com/Hiteshsai007> > > > > Sai Vidya Institute of Technology, India > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > <mailto:[email protected]> > > > For additional commands, e-mail: [email protected] > > > <mailto:[email protected]> > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
