... and (sorry, can't stop) when you have a "sus" dependency, you can diff classpath/tree https://gist.github.com/cstamas/f4d1552491eb503120a69deee9799737
These tools are essential to get awareness about your classpath. On Thu, 18 Jun 2026 at 22:09, Tamás Cservenák <[email protected]> wrote: > > 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]
