[ 
https://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276343#comment-276343
 ] 

Chas Emerick commented on MNG-5087:
-----------------------------------

Confirmed — using aether 1.12 with Maven 3.0.3 resolves this issue.

FYI for others hitting this, the only place I could find aether binaries was 
[central|http://repo1.maven.org/maven2/org/sonatype/aether/].  The artifacts in 
question are -api, -connector-wagon, -impl, -spi, and -util.

It looks like aether 1.12 was released on 5/30, and other notes around on the 
'nets seem to indicate that aether 1.12 fixes a number of problems with maven 
3.0.3.  Anything that can be done to get a v3.0.4 maven release out that 
includes aether 1.12 would be greatly appreciated.

Thanks :-)

> Maven 3 dependency resolution fails until maven-metadata-local.xml files 
> (created by maven-invoker-plugin) are deleted
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: MNG-5087
>                 URL: https://jira.codehaus.org/browse/MNG-5087
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Dependencies, Integration Tests
>    Affects Versions: 3.0.2, 3.0.3
>         Environment: Mac OS X 10.6.x, Java 1.6.0_24
>            Reporter: Chas Emerick
>
> In one of my Maven projects, dependency resolution will succeed once, then 
> fail for later build attempts:
> {code}
> [WARNING] The POM for commons-logging:commons-logging:jar:1.1.1 is missing, 
> no dependency information available
> [WARNING] The POM for commons-httpclient:commons-httpclient:jar:3.1 is 
> missing, no dependency information available
> [WARNING] The POM for javax.mail:mail:jar:1.4.4 is missing, no dependency 
> information available
> {code}
> ...and so on, until I delete the {{maven-metadata-local.xml}} files 
> corresponding to the failing artifacts (e.g. 
> {{~/.m2/repository/commons-logging/commons-logging/maven-metadata-local.xml}}),
>  which appear to be created by maven-invoker-plugin:install. After those 
> files are deleted, the next {{mvn}} invocation proceeds properly; the 
> metadata files are restored by that invocation (presumably as part of the 
> process of checking my upstream repositories/mirrors for updated artifacts), 
> and I am again presented with the above errors until I again delete the 
> metadata files.
> This is repeatable, even after starting with a completely fresh local 
> repository. Note that Maven 2.2.1 does *NOT* exhibit this problem.
> FYI, I'm not using an integration-testing-only local repo 
> [http://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html#localRepositoryPath|as
>  described here], simply because doing so causes the re-downloading of all 
> transitive dependencies 
> ([http://maven.apache.org/plugins/maven-invoker-plugin/examples/fast-use.html|unless
>  you want to maintain an integration-specific settings.xml file!!!]). I've 
> used the invoker plugin with a variety of other projects in this way with 
> good results ([http://github.com/clojure/tools.nrepl|example]) -- certainly 
> never encountering a borked local repository in the process like this.
> Here's an affected project: 
> [https://github.com/cemerick/rummage/tree/1.3.0-compat|the 1.3.0-compat 
> branch of rummage]. To reproduce, just clone that repo, checkout 
> {{1.3.0-compat}}, and:
> {code}
> > mvn clean test
> # no error -- can run this and other builds that don't involve 
> maven-invoker-plugin all day w/o problems
> > mvn clean integration-test
> # FAIL: "Could not resolve dependencies", with warnings as noted above
> > mvn clean test
> # FAIL: "Could not resolve dependencies", with warnings as noted above
> {code}
> Once the local repository is broken (by the generation of the 
> {{maven-metadata-local.xml}} files, AFAICT), no builds will get past the 
> dependency resolution stage.
> Running mvn -X reveals lines like this for each artifact that is later 
> apparently not found:
> {code}
> [DEBUG] Verifying availability of 
> /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar from []
> {code}
> Of course, 
> {{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar}} et al. 
> does exist, as does 
> {{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.pom}}.
> I'm assuming this is a bug in Maven 3's core dependency resolution mechanisms 
> (as opposed to maven-invoker-plugin) since Maven 2.2.1 doesn't exhibit the 
> behaviour.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to