maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Vowles (JIRA)" <j...@codehaus.org>
Subject [jira] Commented: (MNG-5084) Resolver for plugins failing
Date Thu, 12 May 2011 10:43:22 GMT

    [ http://jira.codehaus.org/browse/MNG-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=266470#action_266470
] 

Richard Vowles commented on MNG-5084:
-------------------------------------

What is strange about the groovy artefact is this appears to relate to its version range.
All of the other artefacts are non-ranged versions and all of them resolve with a remote repository.
ONLY groovy (because of its version range) resolves to a local repository. 

Tracing it further, it appears in the org.sonatype.aether.impl.internal.DefaultArtifactResolver
on line 314, because the version resolver (from line 276 of the same file) does not specify
that the repository used is a LocalRepository, it never gets processed, so the artefact is
null in the resulting resolved list.

> 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

        

Mime
View raw message