Maven 3 dependency resolution will work until the maven-metadata-local.xml files are deleted [associated with the maven-invoker-plugin]

In one of my Maven projects, resolving dependencies will succeed once, then fail for subsequent 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 corresponding to the damaging artifacts (e.g. ~/.m2/repository/commons-logging/commons-logging/maven-metadata-local.xml ). After deleting these files, the next mvn call is executed correctly; metadata files are restored by this call (presumably as part of the process of checking my upstream repositories / mirrors for updated artifacts), and I get the above errors again until I delete the metadata files again.

This affects several projects, although it appears to be limited to a specific set of dependencies. I suppose I could go nuclear and tear down my local repo, but I would like to understand what the problem is.

Thoughts?

Update: It looks like a maven-invoker-plugin (which these assemblies use for general purpose testing integration), which creates these maven-metadata-local.xml . I do not use the local repo that is described here , simply because it leads to reloading all the transitive dependencies ( if you do not want to support the settings.xml !!! I used the invoker plugin with a lot of other projects in this way with good results - of course, never running into the wedge of the local repository in this process.

Update 2 OK, this is repeatable, even after starting with a completely new local repository. This is on OS X, Java 1.6.0_24 with Maven 3.0.3; note that Maven 2.2.1 shows NOT this problem.

Here is one of the projects under consideration: 1.3.0-compat branch of rummage . Playback:

 > 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 borked repository (by generating the maven-metadata-local.xml , AFAICT files), no assemblies will go through the dependency resolution stage.

Running mvn -X shows lines similar to this for every artifact that apparently did not appear later:

 [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. exists, like /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.pom . Completely puzzled. At this point, I assume this is a bug in Maven 3 (or some basic library), now I see that 2.2.1 is clean.

Update 3 Error report submitted with the Maven project .

+7
source share
3 answers

This problem was resolved on air 1.12, one revolution above the air library 1.11, which comes with Maven 3.0.3. Replacing ether 1.11 with 1.12 in one Maven installation leads to the expected behavior ( as indicated in the error I filed ). Here's hoping Maven 3.0.4 is released with ASAP broadcast 1.12. :-)

+5
source

You didn’t mention that you might have tried, perhaps you haven’t tried this: adding the -U option to force the update? (perhaps this -U option applies only to SNAPSHOT ...)

0
source

I saw similar errors caused by corrupted files in my local repository. For example, if the download failed or the file in the remote repository changed after it was downloaded. Deleting damaged directories in ~/.m2 fixed.

0
source

All Articles