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]> 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 > [2] > https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html > [3] 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 > > Sai Vidya Institute of Technology, India > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
