Perché Maven scarica ogni volta maven-metadata.xml?

116

Di seguito è riportato l'errore che di solito ricevo quando la mia connessione Internet è irregolare quando provo a creare un'applicazione web con Maven.

La mia domanda è questa, perché Maven deve sempre scaricare ogni volta che la stessa app è stata creata in precedenza.

Cosa potrebbe esserci di sbagliato nella mia configurazione che fa scaricare Maven ogni volta?

Di seguito è riportato un errore che ricevo quando provo a creare offline:

[INFO] ------------------------------------------------------------------------
[INFO] Building mywebapp 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: https://raw.github.com/pagecrumb/mungo/mvn-repo/com/pagecrumb/mungo/0.0.1-SNAPSHOT/maven-metadata.xml

[WARNING] Could not transfer metadata com.mywebapp:mungo:0.0.1-SNAPSHOT/maven-metadata.xml 
from/to mungo-mvn-repo (https://raw.github.com/pagecrumb/mungo/mvn-repo/): raw.github.com
[INFO] 
[INFO] --- maven-war-plugin:2.1.1:war (default-cli) @ mywebapp ---
[INFO] Packaging webapp
[INFO] Assembling webapp [mywebapp] in [D:\workspace\web\target\mywebapp-1.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources [D:\workspace\web\src\main\webapp]
[INFO] Webapp assembled in [1237 msecs]
[INFO] Building war: D:\workspace\web\target\mywebapp-1.0-SNAPSHOT.war
[WARNING] Warning: selected war files include a WEB-INF/web.xml which will be ignored 
(webxml attribute is missing from war task, 
or ignoreWebxml attribute is specified as 'true')
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building com.mywebapp [com.mywebapp] 0.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-release-plugin/2.1/maven-release-plugin-2.1.pom

[WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-release-plugin:2.1: Plugin org.apache.maven.plugins:maven-release-plugin:2.1 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-release-plugin:jar:2.1
Downloading: http://download.java.net/maven/2/org/apache/maven/plugins/maven-metadata.xml
Downloading: http://download.java.net/maven/2/org/codehaus/mojo/maven-metadata.xml

397/397 B   

Downloaded: http://download.java.net/maven/2/org/codehaus/mojo/maven-metadata.xml (397 B at 0.0 KB/sec)
[WARNING] Failure to transfer org.apache.maven.plugins:maven-war-plugin/maven-metadata.xml from http://download.java.net/maven/2 was cached in the local repository, resolution will not be reattempted until the update interval of maven2-repository.dev.java.net has elapsed or updates are forced. Original error: Could not transfer metadata org.apache.maven.plugins:maven-war-plugin/maven-metadata.xml from/to maven2-repository.dev.java.net (http://download.java.net/maven/2): download.java.net
[INFO] 
[INFO] --- maven-war-plugin:2.3:war (default-cli) @ mywebapp-build ---
[INFO] Packaging webapp
[INFO] Assembling webapp [mywebapp-build] in [D:\workspace\target\mywebapp-build-0.0.1-SNAPSHOT]
[INFO] Processing war project
[INFO] Webapp assembled in [15 msecs]
[INFO] Building war: D:\workspace\target\mywebapp-build-0.0.1-SNAPSHOT.war
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] mywebapp ..................................... SUCCESS [27.999s]
[INFO] com.mywebapp [com.mywebapp] ..................... FAILURE [1:00.406s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:41.409s
[INFO] Finished at: Tue May 07 22:13:38 SGT 2013
[INFO] Final Memory: 11M/28M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.3:war 
(default-cli) on project mywebapp-build: Error assembling WAR: webxml attribute is required (or pre-existing WEB-INF/web.xml if executing in update mode)

— quark
fonte

2

L'accesso ai metadati in caso di SNAPSHOT è necessario per informare Maven sugli SNAPSHOT di nuova creazione ecc.

— khmarbaise

7

Non so perché, ma puoi evitarlo usando l'opzione -o comemvn clean install -o

— ant

In realtà, l'errore su cui la build fallisce è "Errore durante l'assemblaggio dell'attributo WAR: webxml è richiesto (o WEB-INF / web.xml preesistente se eseguito in modalità di aggiornamento)". Quindi dovresti aggiustarlo. Non riesco a immaginare che sia correlato alla tua connessione Internet. Gli avvisi sulla risoluzione delle dipendenze sono proprio questo: avvisi. Non sono la causa ultima del fallimento della tua build.

— Frans

Forse puoi chiarire la tua domanda poiché sembra che tu abbia due domande: 1) Perché la mia build non funziona? 2) Perché Maven sta cercando di scaricare i metadati? La risposta di user944849 fa molto per rispondere 2). Se questo risponde alla tua domanda, dovresti accettarlo.

— Frans

L'aggiornamento dei metadati delle istantanee può essere evitato utilizzando -nsu, --no-snapshot-updatesopzione conmvn

— Janaka Bandara

127

Cerca settings.xmll' <repositories>elemento nel tuo (o, possibilmente, nel POM genitore o aziendale del tuo progetto) . Assomiglierà al seguente.

<repositories>
    <repository>
        <id>central</id>
        <url>http://gotoNexus</url>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>always</updatePolicy>
        </snapshots>
        <releases>
            <enabled>true</enabled>
            <updatePolicy>daily</updatePolicy>
        </releases>
    </repository>
</repositories>

Nota l' <updatePolicy>elemento. L'esempio dice a Maven di contattare il repository remoto (Nexus nel mio caso, Maven Central se non stai utilizzando il tuo repository remoto) ogni volta che Maven ha bisogno di recuperare un artefatto di snapshot durante una build, controllando per vedere se c'è una copia più recente. I metadati sono necessari per questo. Se è presente una copia più recente, Maven la scarica nel repository locale.

Nell'esempio, per i rilasci, la politica è dailyche controllerà durante la prima build della giornata. neverè anche un'opzione valida, come descritto nei documenti delle impostazioni di Maven .

I plugin vengono risolti separatamente. Potresti avere repository configurati anche per quelli, con diverse politiche di aggiornamento se lo desideri.

<pluginRepositories>
    <pluginRepository>
        <id>central</id>
        <url>http://gotoNexus</url>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>daily</updatePolicy>
        </snapshots>
        <releases>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
        </releases>
    </pluginRepository>
</pluginRepositories>

Qualcun altro ha menzionato l' -oopzione. Se lo usi, Maven funziona in modalità "offline". Sa di avere solo un repository locale e non contatterà il repository remoto per aggiornare gli artefatti, indipendentemente dai criteri di aggiornamento utilizzati.

— user944849
fonte

2

La domanda è: perché non è sempre "mai" (cosa che penso dovrebbe essere)? Perché hai bisogno di aggiornamenti giornalieri o sempre?

— Leon

@Leon Durante il ciclo di sviluppo intermedio il tuo progetto potrebbe avere dipendenze '-SNAPSHOT' per le quali potresti voler scegliere sempre l'ultima versione costruita - almeno, su un sistema CI probabilmente lo faresti, uno sviluppatore potrebbe avere preferenze diverse - stabilità della build commerciale vs ottenere le ultime modifiche. Ciò che i documenti di Maven (tipicamente, sfortunatamente) non riescono a chiarire sono i valori predefiniti per questi se non è impostato nulla.

— Ed Randall

1

La migliore pratica è che una volta rilasciato un artefatto non cambia mai, quindi <updatePolicy> mai </updatePolicy> dovrebbe essere appropriato per loro.

— Ed Randall

Ma cosa succede se aggiorni le tue dipendenze POM a una nuova versione? Non verrà mai aggiornato?

— Philip Rego

1

@PhilipRego: updatePolicy si applica per artefatto. Se modifichi un numero di versione o un ID gruppo / elemento, si tratta di un elemento diverso. Se updatePolicy è "mai", l'elemento verrà scaricato una volta, a meno che l'aggiornamento non venga forzato -Uo l'elemento venga rimosso dal repository locale e quindi debba essere scaricato di nuovo.

— user944849

31

È possibile utilizzare la bandiera -o,--offline "Work offline"per impedirlo.

Come questo:

maven compile -o

— JFC
fonte

Credo che questa dovrebbe essere la risposta corretta, perché puoi semplicemente chiamare questo comando quando la tua connessione Internet è flanky. E questo era ciò che è stato chiesto ...

— Quindi S

13

Suppongo perché non hai specificato la versione del plug-in, quindi innesca il download dei metadati associati per ottenere l'ultimo.

Altrimenti hai provato a forzare l'utilizzo del repo locale usando -o?

— parlantina
fonte

Allora come si specifica la versione del plugin? Sono sicuro di avere la versione impostata nel POM ... puoi essere più specifico?

— quark

beh, se hai un versionelemento all'interno plugindell'elemento, lo hai effettivamente configurato, se è così sono a corto di idee ... Buona fortuna

— Gab

nel mio caso la versione era un intervallo [12.1 12.2) e la cache dei metadati era impostata su 24 ore in modo da verificare la presenza di una versione più recente alla prima build ogni giorno

— mzzzzb

E i plugin predefiniti? come maven-surefire-common, che non ho specificato?

— yegeniy

la loro versione è corretta per una data versione di Maven, ma puoi forzarne una diversa usando la pluginManagementsezione

— Gab

0

Non ho ancora studiato, quando Maven fa quale ricerca, ma per ottenere build stabili e riproducibili, consiglio vivamente di non accedere direttamente ai Respository Maven ma di utilizzare un Maven Repository Manager come Nexus.

Ecco il tutorial su come configurare il file delle impostazioni:

http://books.sonatype.com/nexus-book/reference/maven-sect-single-group.html

http://maven.apache.org/repository-management.html

— color pulce
fonte

@acdcjunior come ho detto, non l'ho ancora studiato. Ma l'utilizzo di un Maven Repository Manager locale risolverà anche la maggior parte di questi problemi (se Maven controlla i metadati accederà solo al tuo Maven Repository Manager)

— Puce

1

IMHO un repo manager è utile solo all'interno di un'organizzazione per evitare download ridondanti e in particolare per distribuire artefatti specifici per questa organizzazione (come i poms principali e i moduli interni). Altrimenti perché aggiungere un mirror aggiuntivo visto che hai già quello locale?

— Gab

@ Puce Non vedo come risolverebbe il problema. Se non vuoi affatto che Maven controlli i metadati attraverso la rete, non importa se controlla da Internet o dal gestore repository Intranet.

— eis

@eis dovrebbe aiutare se la "connessione a Internet è flanky" o se uno dei server di repository non è attualmente disponibile, poiché stai accedendo solo al gestore di repository maven nella tua LAN.

— Puce

@Gap Mentre i repo manager sono particolarmente utili in un'organizzazione per i motivi che hai menzionato, un repo manager è anche importante per ottenere build stabili e riproducibili, che è qualcosa a cui di solito miro anche se sono attualmente l'unico sviluppatore del progetto. Assicura che posso cancellare il mio repository locale e sono ancora in grado di riprodurre tutte le build e che altri sviluppatori potrebbero facilmente partecipare al progetto. Lo assicuro con Jenkins, che a volte viene eseguito anche localmente, accede anche al gestore dei repository e aiuta anche a rilasciare i miei progetti -> 2 utenti che accedono al gestore dei repository: Jenkins ed io

— Puce

0

Maven lo fa perché la tua dipendenza è in una versione SNAPSHOT e maven non ha modo di rilevare eventuali modifiche apportate a quella versione snapshot nel repository. Rilascia il tuo artefatto e cambia la versione in pom.xml in quella versione e Maven non recupererà più il file di metadati.

— Tomask
fonte