Può Maven 3 riscaricare i file danneggiati invece di fallire la compilazione?

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 

I file danneggiati si verificano in ~/.m2, tutti ne sono a conoscenza. Ripararlo è facile come rimuovere i file corrotti, quindi Maven può riscaricarlo. Tuttavia, non voglio eseguire manualmente il grep dei log, collegarmi all'agent build e rimuoverli manualmente. Le build affidabili dovrebbero essere in grado di gestire tali problemi.

C'è un modo per rendere Maven scaricare i file danneggiati invece di fallire la compilazione? Non voglio rimuovere ~/.m2 prima che ogni generazione venga eseguita in quanto renderebbe la costruzione molto lenta.

Perché succede? Uno dei miei clienti ha un'infrastruttura rotta. Le macchine virtuali vengono riavviate molto spesso senza alcun preavviso. E poiché le build vengono eseguite la maggior parte delle volte, i file vengono corrotti ad es. ~/.m2. Non c'è nulla che io possa cambiare in questa faccenda, sono i loro server e la loro politica - o semplicemente l'inettitudine. Ma sono io che devo sistemare le build a mano.

Answer 1

Fino a Maven 3.0.4 non c'è modo di risolverlo con una sola chiamata di Maven.

Quello che si potrebbe fare è scrivere un plugin di aggregatore che passi attraverso ciascuno dei moduli nel reattore e risolva le loro dipendenze tramite le chiamate API (piuttosto che l'annotazione mojo) consentendo di rilevare errori, eliminare e riprovare.

Non sarebbe prendere tutti i casi (ad esempio i plug-dipendenze), ma se hai fatto qualcosa di simile

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

Sarebbe più affidabile.

Se siete felici di richiedere Maven 3.x si potrebbe scrivere un estensione di compilazione e rilasciarlo in $MAVEN_HOME/lib e l'estensione di compilazione potrebbe fare gli stessi trucchi come il plug-in, ma perché è in gioco prima risoluzione plug-in, potrebbe prendere i casi con i plugin.

Un sacco di lavoro, personalmente un buon MRM rende ridicolo il redownlading, e in 8 anni di utilizzo di Maven ho forse avuto una corruzione di repository locale forse 3-4 volte ... E di quei tempi tutti uno bar erano dove io ha avuto più repository in gioco e metadata (pom) è stato risolto da uno mentre l'artefatto da un altro ... Un solo caso era "l'HTML scaricato per errore" ... Tutti sarebbero stati fermati da un MRM