[
http://jira.codehaus.org/browse/MNG-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-2098.
----------------------------------
Assignee: Benjamin Bentmann (was: Jason van Zyl)
Resolution: Fixed
Fix Version/s: (was: 3.x)
3.0-alpha-3
Fixed in [r818829|http://svn.apache.org/viewvc?view=rev&revision=818829].
> 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: Benjamin Bentmann
> Fix For: 3.0-alpha-3
>
> 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
