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 brettporter wrote: > > 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. > -- View this message in context: http://www.nabble.com/Repo-selection--Was%3A-JIRA-MNG-2098--tf1164364s177.html#a12011447 Sent from the Maven Developers mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
