[ http://jira.codehaus.org/browse/MNG-2098?page=comments#action_60188 ]
Brett Porter commented on MNG-2098: ----------------------------------- from dev@: Setting the repository is not exactly a side effect of resolving metadata, but I see why its a bug. However, the collector can't select the repository as it doesn't know where it will be present. The current logic is based on the use of snapshots - it considered that releases would only be in one so the first found is used, whereas for snapshots all must be checked and the newest used. I believe it works for the latter. It seems to be falling down only for version ranges, correct? I had thought these should also operate as a transformation but that doesn't sit with the whole resolution technique. The actual version selection should be assigning a single repository to it where the correct version was found. This area of the code needs a lot more tests, in the order of what the collector itself has. I suspect doing so will probably yield a lot of clues for a better design also. > 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 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0.2 > Reporter: Garrett Conaty > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
