[
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17445771#comment-17445771
]
Tuomas Kiviaho commented on MRESOLVER-224:
------------------------------------------
Here are the metadatas to give a clearer picture of the local repo state just
prior to invoker:integration-test goal execution. It seems that invoker:install
goal generates (partial???) {{maven-metadata-local.xml}} that I may have
mistaken as the actual local repository while debugging since they both point
to the same location in my settings. And for sure that one is missing
references to pom and other artifacts.
But still it's the weird aftermath that
{{DefaultVersionResolver::resolveVersion}} applies when the metadataresults
have been already merged together successfully. It can't be just an
optimization to see if the metadata of the local repo is newer than the remote
since that's done already so have no idea what the code snippet in my first
comment is all about.
This logic is ultimately causing the failure and invoker is just a contributor
to the cause.
As a work-a-round I need to start finding an alternative/patch for
invoker:install for the time being, but it would be nice to get clarification
on what is going on with the version resolver post processing the snapshot
classifiers repo in such way.
{code:xml|title=maven-metadata-local.xml}
<metadata>
<groupId>mygroupid</groupId>
<artifactId>myartifactid</artifactId>
<version>x.y.z-SNAPSHOT</version>
<versioning>
<snapshot>
<localCopy>true</localCopy>
</snapshot>
<lastUpdated>20211117135742</lastUpdated>
</versioning>
</metadata>
{code}
{code:xml|title=maven-metadata-repo.xml}
<?xml version="1.0" encoding="UTF-8"?>
<metadata modelVersion="1.1.0">
<groupId>mygroupid</groupId>
<artifactId>myartifactid</artifactId>
<version>x.y.z-SNAPSHOT</version>
<versioning>
<snapshot>
<timestamp>20211112.112753</timestamp>
<buildNumber>2</buildNumber>
</snapshot>
<lastUpdated>20211112112753</lastUpdated>
<snapshotVersions>
<snapshotVersion>
<extension>jar</extension>
<value>x.y.z-20211112.112753-2</value>
<updated>20211112112753</updated>
</snapshotVersion>
<snapshotVersion>
<extension>pom</extension>
<value>x.y.z-20211112.112753-2</value>
<updated>20211112112753</updated>
</snapshotVersion>
<snapshotVersion>
<classifier>myclassifier</classifier>
<extension>jar</extension>
<value>x.y.z-20211112.112753-2</value>
<updated>20211112112753</updated>
</snapshotVersion>
<snapshotVersion>
<classifier>sources</classifier>
<extension>jar</extension>
<value>x.y.z-20211112.112753-2</value>
<updated>20211112112753</updated>
</snapshotVersion>
</snapshotVersions>
</versioning>
</metadata>
{code}
> DefaultVersionResolver is inflicting ArtifactNotFoundException for
> classifiers with SNAPSHOT version
> ----------------------------------------------------------------------------------------------------
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
> Affects Versions: 1.6.3
> Reporter: Tuomas Kiviaho
> Priority: Major
>
> I use classifier artifact along with the artifact itself as a dependency in a
> Maven Invoker Plugin project. The project that calls the invoker has the
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus
> downloading of the dependency artifact.When invoker is called the artifact is
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of
> the SNAPSHOT<myclassifier>:jar artifact that is now being resolved with the
> already downloaded SNAPSHOT key. Since the local version is newer than the
> repo version the DefaultVersionResolver thinks SNAPSHOT<myclassifier>:jar to
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT<myclassifier>:jar doesn't exist in the local repo there
> are no remote report left to try the DefaultArtifactResolver fails ultimately
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact
> <mygroupid>.<myartifactid>:jar:<myclassifier>:<mybaseversion>-SNAPSHOT from
> []{code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
