Re: [GSoC 2027] Proposal idea: dependency:insig ht — tracing why an artifact is on the classpath

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
>