Can Maven 3 redownload broken files instead of failing the build?

Question

[WARNING] The POM for org.testng:testng:jar:5.14.10 is invalid,
          transitive dependencies (if any) will not be available: 1 problem was
          encountered while building the effective model for
          org.testng:testng:5.14.10

[FATAL]   Non-readable POM
          /home/teamcity/.m2/repository/org/sonatype/oss/oss-parent/3/oss-parent-3.pom:
          input contained no data @
          /home/teamcity/.m2/repository/org/sonatype/oss/oss-parent/3/oss-parent-3.pom

Corrupted files happen in ~/.m2, everyone knows about it. Fixing it is as easy as removing the corrupted files so Maven can redownload it. However, I don't want to manually grep the logs, connect to the build agent and remove those files by hand. Reliable builds should be capable of dealing with such problems.

Is there any way to make Maven redownload corrupted files instead of failing the build? I don't want to remove ~/.m2 before each build is performed as it would make the build really slow.

Why that happens? One of my customer has got a broken infrastructure. Virtual machines are being restarted very often without any notice. And since builds are performed most of the time, files get corrupted in e.g. ~/.m2. There is nothing I can change in this matter, it's their servers, and their policy - or just ineptness. But it's me who has to fix the builds by hand.

Answer 1

Up as far as Maven 3.0.4 there is no way to solve this with one invocation of maven.

What you could do is write an aggregator plugin that steps through each of the modules in the reactor and resolves their dependencies via API calls (rather than mojo annotation) allowing to catch failures and purge and retry.

It wouldn't catch every case (for example plugin dependencies) but if you did something like

$ mvn org.mine.maven:resolve-all:resolve-all || rm -rvf ~/.m2/repository
$ mvn clean verify

It would be more reliable.

If you are happy to require Maven 3.x you could write a build extension and drop it in $MAVEN_HOME/lib and the build extension could do the same tricks as the plugin, but because it is in play before plugin resolution, it could catch the cases with plugins.

A lot of work, personally a good MRM makes redownlading silly fast, and in 8 years of using Maven I have maybe had local repo corruption maybe 3-4 times... And of those times all bar one were where I had multiple repositories in play and metadata (pom) was resolved form one while the artifact from another... Only one case was the "downloaded HTML by mistake"... All of them would be stopped by an MRM