[
http://jira.codehaus.org/browse/MNG-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=266465#action_266465
]
Richard Vowles commented on MNG-5084:
-------------------------------------
I have now spent some hours debugging through aether-1.11 (which is used in
maven 3.0.3) and what I have found is this.
After the first build, with an empty repository, maven downloads Groovy 1.7.10
and puts it in the local repository and creates a maven-metadata-local.xml file
for it which includes only one version (1.7.10). It downloads the poms for all
the other versions in the version range. This occurs because of the code in
org.sonatype.aether.impl.internal.DefaultDependencyCollector on line 368. Any
subsequent attempt to use the artefact (in an invoker plugin test or simply by
running verify again on the artefact) causes it to be found locally. The
rangeResult on line 481 of the same file returns 1.7.0 -> 1.7.10 with all but
1.7.10 coming from a remote repository.
The if directly following 481 (on 482 to 493) checks to see if the repo NOT
remote or if it is NOT null (i.e. it is local). If it is local, it throws it
away on line 492. Thus the artefact is left with no repository to resolve from.
This appears to be picked up later by the resolver, which checks for the key
"groovy-all-1.7.10.jar>=" in the _maven.repositories file in the groovy-1.7.10
local repository directory, and not finding it (because maven has set it to
"groovy-all-1.7.10.jar>central=") causes maven to not be able to find the
artefact. I will attempt to track this bit down again.
> Resolver for plugins failing
> ----------------------------
>
> Key: MNG-5084
> URL: http://jira.codehaus.org/browse/MNG-5084
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
> Affects Versions: 3.0.3
> Environment: JDK 1.6.24, Mac OS X
> Reporter: Richard Vowles
> Priority: Critical
> Attachments: simple-plugin.tar
>
>
> We are at a standstill with the easyb plugin for maven as we cannot get it to
> resolve artefacts when doing its integration tests. Installing it without
> them and then using it also fails with resolution problems.
> I downloaded the source and did a remote debug, the resolution seems to
> *require* that the artefact that is missing be deployed locally, even if
> these artefacts are in central and are listed in the _maven.repositories file
> as being from central. It seems to be looking for them as
> groovy-all-1.7.10.jar>= (for example) even when there is a
> groovy-all-1.7.10.jar>central= and it has previously just downloaded it from
> central.
> I have created a trivial sample, that builds nothing but has an integration
> test (which also fails). To reproduce, you need to have *no* settings.xml and
> clear your repository out (rename it to something else) so you have what
> appears to be a bare repo. Then run a mvn clean verify (using 3.0.3) and it
> builds, installs the plugin, runs the integration test and fails. If you edit
> the integration test and specify the version and mvn clean verify again, it
> still fails (so it has nothing to do with the invoker plugin).
--
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
