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]
