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