Maven
  1. Maven
  2. MNG-5087

Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.2, 3.0.3
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      Mac OS X 10.6.x, Java 1.6.0_24
    • Complexity:
      Intermediate
    • Testcase included:
      yes
    • Number of attachments :
      0

      Description

      In one of my Maven projects, dependency resolution will succeed once, then fail for later build attempts:

      [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
      

      ...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:

      > 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
      

      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:

      [DEBUG] Verifying availability of /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar from []
      

      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.

        Activity

        Chas Emerick made changes -
        Field Original Value New Value
        Status Open [ 1 ] Closed [ 6 ]
        Resolution Duplicate [ 3 ]
        Benjamin Bentmann made changes -
        Resolution Duplicate [ 3 ]
        Status Closed [ 6 ] Reopened [ 4 ]
        Jason van Zyl made changes -
        Assignee Jason van Zyl [ jason ]
        Jason van Zyl made changes -
        Resolution Fixed [ 1 ]
        Status Reopened [ 4 ] Closed [ 6 ]

          People

          • Assignee:
            Jason van Zyl
            Reporter:
            Chas Emerick
          • Votes:
            6 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: