Description
Robert Stupp opened MNG-8724 and commented
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:
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);
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.
Affects: 4.0.0-rc-3