Robert Stupp created MNG-8724:
---------------------------------
Summary: DefaultArtifactCoordinates ignores 'extension' in
equals+hashCode
Key: MNG-8724
URL: https://issues.apache.org/jira/browse/MNG-8724
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 4.0.0-rc-3
Reporter: Robert Stupp
I've got a small use case where I have to resolve artifacts - and I'm using
Maven for this use case. The implementation has to first inspect the jar file
and then the corresponding pom.
It's is functionally equivalent to the following pseudo code:
{code:java}
Session session = ...;
// in one function...
ArtifactCoordinates jarCoordinates =
session.createArtifactCoordinates("group:artifact:version");
Collection<DownloadedArtifact> jarArtifacts =
session.resolveArtifacts(jarCoordinates);
// in another function...
ArtifactCoordinates pomCoordinates =
session.createArtifactCoordinates("group:artifact:pom:version");
Collection<DownloadedArtifact> pomArtifacts =
session.resolveArtifacts(pomCoordinates);
{code}
The interesting part is that {{pomArtifacts}} does not yield the pom, but the
previously resolved jar.
I debugged a bit and stumbled upon the implementation
{{AbstractSession.request()}} using a request-cache, which is nice to see.
However, the {{equals()}} + {{hashCode()}} implementations of
{{DefaultArtifactCoordinates}} do not consider {{{}getExtension(){}}}. This
lets the request-cache yield the previously requested jar, not the pom.
I suspect that this would also yield to wrong results for different results
when requesting e.g. a tarball vs a zip with the same (or no) classifier.
TL;DR I think that {{DefaultArtifactCoordinates} should include
{{getExtension()}} in its {{equals()}} and {{hashCode()}} implementations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
