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]> 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]> > 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] >> >>
