Maven 3 dependency resolution fails until maven-metadata-local.xml files
(created by maven-invoker-plugin) are deleted
----------------------------------------------------------------------------------------------------------------------
Key: MNG-5087
URL: http://jira.codehaus.org/browse/MNG-5087
Project: Maven 2 & 3
Issue Type: Bug
Components: Dependencies, Integration Tests
Affects Versions: 3.0.3, 3.0.2
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.
-
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
