You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Chas Emerick (JIRA)" <ji...@codehaus.org> on 2011/05/08 13:16:22 UTC
[jira] Created: (MNG-5087) Maven 3 dependency resolution fails
until maven-metadata-local.xml files (created by maven-invoker-plugin) are
deleted
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
[jira] (MNG-5087) Maven 3 dependency resolution fails until
maven-metadata-local.xml files (created by maven-invoker-plugin) are
deleted
Posted by "Jason van Zyl (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason van Zyl updated MNG-5087:
-------------------------------
Assignee: Jason van Zyl
> 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
> Assignee: Jason van Zyl
>
> 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, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5087) Maven 3 dependency resolution fails until
maven-metadata-local.xml files (created by maven-invoker-plugin) are
deleted
Posted by "Chas Emerick (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chas Emerick closed MNG-5087.
-----------------------------
Resolution: Duplicate
Fixed in aether 1.12, will be fixed in maven when a new release is cut that includes 1.12.
> 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
[jira] Reopened: (MNG-5087) Maven 3 dependency resolution fails
until maven-metadata-local.xml files (created by maven-invoker-plugin) are
deleted
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann reopened MNG-5087:
------------------------------------
And until aether:1.12 is actually included, this issue remains unresolved.
> 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
[jira] Commented: (MNG-5087) Maven 3 dependency resolution fails
until maven-metadata-local.xml files (created by maven-invoker-plugin) are
deleted
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274498#comment-274498 ]
Benjamin Bentmann commented on MNG-5087:
----------------------------------------
The hotfix for this is to replace {{<maven-home>/lib/aether-\*-1.11.jar}}'s with their 1.12 equivalents.
> 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
[jira] Commented: (MNG-5087) Maven 3 dependency resolution fails
until maven-metadata-local.xml files (created by maven-invoker-plugin) are
deleted
Posted by "Chas Emerick (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (MNG-5087) Maven 3 dependency resolution fails
until maven-metadata-local.xml files (created by maven-invoker-plugin) are
deleted
Posted by "David Matejcek (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274486#comment-274486 ]
David Matejcek commented on MNG-5087:
-------------------------------------
I have an idea - I switched between Maven2 and Maven3. Maybe if the artifact is downloaded by Maven2, Maven3 skips updating due to some incompatibility?
> 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
[jira] Commented: (MNG-5087) Maven 3 dependency resolution fails
until maven-metadata-local.xml files (created by maven-invoker-plugin) are
deleted
Posted by "Chas Emerick (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=265999#action_265999 ]
Chas Emerick commented on MNG-5087:
-----------------------------------
I mistakenly swapped the order of link and link text in my report, but it doesn't look like I have privs to edit the ticket sorry!
> 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.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.
-
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
[jira] Commented: (MNG-5087) Maven 3 dependency resolution fails
until maven-metadata-local.xml files (created by maven-invoker-plugin) are
deleted
Posted by "David Matejcek (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274485#comment-274485 ]
David Matejcek commented on MNG-5087:
-------------------------------------
I have the same problem, deployed SNAPSHOT version from one machine to the repository server yesterday, but today another machine does not update the artifact, even with -U.
When I deleted maven-metadata-local.xml of the artifact, the dependency was updated (even without -U).
There wasn't any problems with Maven2.
Maven 3.0.3, Kubuntu 10.04 - 2.6.32-32-generic, Sun JDK 1.6.0.24.
> 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