[jira] Commented: (MNG-2098) Artifact resolver incorrectly selects repository which doesn't contain the selected version

["Casey Butterworth (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MNG-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104055 ] 

Casey Butterworth commented on MNG-2098:
----------------------------------------

I can confirm that this is still happening in 2.0.6 and 2.0.7. However, the issue is more substantial than originally thought, i.e. not only happening for ranges but also for LATEST version transformation.

In our scenario, we are trying to resolve org.codehaus.mojo:jaxb2-maven-plugin and have not specified a version (i.e. LATEST). The following 2 repositories are specified for this project and both have the artifact available (central has the releases, codehaus.snapshot the snapshots).

central: http://repo1.maven.org/maven2/
codehaus.snapshot: http://snapshots.repository.codehaus.org/

In this scenario, DefaultRepositoryMetadataManager.mergeMetadata (line 167) is correctly updating the MetaData to include the versions from both the central and snapshot repositories. However, the repositories are processed in the order (1) central (2) codehaus.snapshot, and therefore the codehaus.snapshot repository is being set as the selected repository (line 169) as the last repo iterated over.

Afterwards, LatestArtifactTransformation.constructVersion() is retrieving the LATEST version (1.2) which is not available in the pre-selected repo (codehaus.snapshot), and the plugin's pom is not retrieved (resulting in a "Artifact not found - using stub model: Unable to locate resource in repository"). In this instance, this causes a ClassDefNotFound as the jaxb2 plugin's pom specifies dependencies.

We are able to work around the problem by (a) specifying a version for the plugin (1.2) or (b) specifying the dependencies in the plugin definition, however, it took a while to get to this stage.

I am reasonably sure that the fix suggested by Garrett would fix the problem.

Let me know if this is not clear enough.

Cheers
Casey

> Artifact resolver incorrectly selects repository which doesn't contain the selected version
> -------------------------------------------------------------------------------------------
>
>                 Key: MNG-2098
>                 URL: http://jira.codehaus.org/browse/MNG-2098
>             Project: Maven 2
>          Issue Type: Bug
>          Components: Artifacts and Repositories
>    Affects Versions: 2.0.2
>            Reporter: Garrett Conaty
>            Assignee: Jason van Zyl
>             Fix For: 2.1.x
>
>         Attachments: MNG-2098.simplefix.diff, pom.xml
>
>
> The current logic for resolution of an artifact which has groupId/artifactId and then a range is for the DefaultArtifactCollector to call MavenMetadataSource and retrieve the available versions and then match the available versions to the range.
> However, a side effect exists in that the DefaultRepositoryMetadataManager in its call to mergeMetadata sets the repository for the artifact.  It currently just sets it to the last repository that had versions to merge.  What occurs here though is that it can be set to a repository that doesn't actually have the artifact that is selected as part of the match of version range to available versions.  Then when this artifact is passed to the resolver to download the JAR it references, it of course can't find it and an exception is thrown.
> So there are a couple of issues here
> 1) Should the DefaultArtifactResolver really use artifact.getRepository() exclusively if it's not null?  Perhaps the Artifact really ought to contain a list of repositories that are acceptable (from the transformation phase) from which to try.  This may be a good enhancment.
> but the more pressing issue is
> 2) Shouldn't the DefaultArtifactCollector actually do the repository selection, not have it be a side effect of getting the metadata.
> The simple patch I've attached solves the problem by just removing the call to setRepository in the mergeMetadata method.  This has the effect that there will be no repository chosen by the time the DefaultArtifactResolver gets a hold of the artifact and it will then go through the list of remoteRepositories until it finds a succesful match.
> What I'd like to do though is really modify the DefaultArtifactCollector and MavenMetadataSource so that the collector can make the decision about what repository/list of repositories to use, and in the very least choose the repository that has the version that was matched in the range.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira