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]
