[
https://issues.apache.org/jira/browse/MDEP-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205867#comment-17205867
]
Michael Boyles commented on MDEP-715:
-------------------------------------
The issue seems to be that a class with the same FQN exists in two dependencies.
When shared-utils dependencies are like this
{code:java}
<dependency>
<groupId>junit</groupId> <!-- has transitive dependency on
hamcrest-core:1.3 -->
<artifactId>junit</artifactId>
<version>4.13</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
<version>2.2</version>
<scope>test</scope>
</dependency>{code}
The hamcrest-core we explicitly declare overrides Junit's. The 2.2 core is
actually deprecated and just contains a text file, but crucially gives us the
transitive dependency to hamcrest:2.2, which has the classes we actually want.
Actually, we only use 1 class, org.hamcrest.CoreMatchers
So in this case we have a transitive dependency on hamcrest:2.2 which we did
not declare, so the output of analyze is *correct*.
However, when we make the seemingly obvious fix:
{code:java}
<!-- junit here -->
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest</artifactId>
<version>2.2</version>
<scope>test</scope>
</dependency> {code}
Then now what we have is a transitive dependency on hamcrest-core:1.3 via Junit
and our own dependency on hamcrest:2.2. Both contain a class with the FQN.
hamcrest-core must "win" the lookup, so the dependency plugin thinks
org.hamcrest.CoreMatchers comes *only* from there. If that assumption were
true, hamcrest-core would be an undeclared transitive dependency through junit,
while hamcrest itself is unnecessary, hence the spurious result.
I found 2 ways you can work around it:
* Move Junit after hamcrest. hamcrest "wins" the ownership of the class so is
now counted as being "used", while hamcrest-core is "unused" (but that's
transitive, so not a warning)
* Exclude the hamcrest-core from junit
—
The ideal fix is less clear to me.
Should we should omit some warning that we found a class that exists in two or
more dependencies, and consider all such dependencies to be used, and advise
them the solve the problem manually (via exclusions etc.)?
> Hamcrest used and unused
> ------------------------
>
> Key: MDEP-715
> URL: https://issues.apache.org/jira/browse/MDEP-715
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
> Reporter: Elliotte Rusty Harold
> Priority: Major
> Labels: S2, intern
>
> This is something I've seen when analyzing several Maven plugins. For
> example, maven-shared-utils circa July 20, 2020:
>
> [WARNING] Used undeclared dependencies found:
> [WARNING] org.hamcrest:hamcrest:jar:2.2:test
> [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test
> [WARNING] Unused declared dependencies found:
> [WARNING] org.hamcrest:hamcrest-core:jar:2.2:test
> [WARNING] org.apache.maven:maven-core:jar:3.1.0:test
> [WARNING] org.codehaus.plexus:plexus-container-default:jar:2.1.0:provided
>
> Easy fix, right? don't declare org.hamcrest:hamcrest-core:jar:2.2:test and
> instead declare org.hamcrest:hamcrest:jar:2.2:test
>
> But when I do that:
>
> [WARNING] Used undeclared dependencies found:
> [WARNING] org.hamcrest:hamcrest-core:jar:1.3:test
> [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test
> [WARNING] Unused declared dependencies found:
> [WARNING] org.hamcrest:hamcrest:jar:2.2:test
> [WARNING] org.apache.maven:maven-core:jar:3.1.0:test
> [WARNING] org.codehaus.plexus:plexus-container-default:jar:2.1.0:provided
>
> Figure out what's going on here and fix it. Is hamcrest-core needed and used
> or not? is hamcrest needed and used or not? Be consistent.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
