2013-05-07 14 views
64

Di seguito è riportato l'errore che di solito ottengo quando la mia connessione Internet è flaccida quando provo a creare un'applicazione web con Maven.Perché Maven sta scaricando maven-metadata.xml ogni volta?

La mia domanda è che, 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 è un errore che ottengo quando provo a costruire 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) 
+2

L'accesso ai metadati in caso di SNAPSHOT del necessario per ottenere Maven informato in merito a ISTANTANEA di nuova creazione, ecc – khmarbaise

+5

Non so perché, ma puoi evitarlo usando l'opzione -o come 'mvn clean install -o ' – ant

+0

In realtà, l'errore in cui la compilazione fallisce è "Errore durante l'assemblaggio WAR: è richiesto l'attributo webxml (o esistente WEB-INF/web.xml se eseguito in modalità di aggiornamento) ". Quindi dovresti sistemarlo. Non riesco a immaginarlo correlato alla tua connessione internet. Gli avvisi di risoluzione delle dipendenze sono solo quelli: avvisi. Non sono la causa principale del fallimento della tua build. – Frans

risposta

81

Cerca nel tuo settings.xml (o, probabilmente, il tuo genitore principale o genitore aziendale POM) per l'elemento <repositories>. 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'elemento <updatePolicy>. L'esempio dice Maven per contattare il repo remoto (Nexus nel mio caso, Maven centrale se non siete usando il proprio repository remoto) qualsiasi Maven momento ha bisogno di recuperare un artefatto un'istantanea durante una generazione, il controllo per vedere se c'è una nuova copia. I metadati sono necessari per questo. Se c'è una copia più recente, Maven la scarica nel repository locale.

Nell'esempio, per le versioni, la politica è daily, quindi verrà verificata durante la prima build della giornata. never è anche un'opzione valida, come descritto in Maven settings docs.

I plug-in vengono risolti separatamente. Potresti avere repository configurati anche per quelli, con differenti 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'opzione -o. Se lo usi, Maven funziona in modalità "offline". Si sa che ha solo un pronti contro termine locali, e non sarà in contatto con il repo remota per aggiornare i manufatti non importa ciò che le politiche di aggiornamento che si usa.

+0

molto buona, grazie! – sunny

+1

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

+0

@Leon Durante il ciclo di sviluppo intermedio il progetto potrebbe avere dipendenze '-SNAPSHOT' per le quali si potrebbe desiderare di scegliere sempre la versione più recente - almeno, su un sistema CI che probabilmente si farebbe, uno sviluppatore potrebbe avere preferenze diverse - creazione di trading stabilità vs ottenere le ultime modifiche. Ciò che i documenti di maven (tipicamente, purtroppo) non riescono a chiarire sono i valori predefiniti per questi se non è impostato nulla. –

0

non ho ancora studiato, quando Maven fa che look-up, ma per ottenere stabili e riproducibili costruisce, vi raccomando vivamente non accedere direttamente a Maven Respositories ma 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

+5

Ma ***" Perché Maven sta scaricando i metadati ogni volta? "*** – acdcjunior

+0

@acdcjunior come I Detto questo, non l'ho ancora studiato. Tuttavia, l'utilizzo di un Maven Repository Manager locale risolverà la maggior parte di questi problemi (se Maven controlla i metadati accederà al Maven Repository Manager) – Puce

+1

IMHO un gestore di repository è utile solo all'interno di un'organizzazione per evitare il download ridondante e in particolare per distribuire gli artefatti specifico per questa organizzazione (come i genitori e i moduli interni). Altrimenti perché aggiungere un mirror aggiuntivo come hai già quello locale? – Gab

12

suppongo perché non è stato specificato la versione plug-in in modo che innesca il download di metadati associati al fine per ottenere l'ultimo.

In caso contrario si è tentato di forzare l'utilizzo del repository locale utilizzando -o?

+0

Quindi come si specifica la versione del plugin? Sono sicuro di avere la versione impostata in POM ... puoi essere più specifico? – xybrek

+0

bene se hai un elemento 'version' dentro l'elemento' plugin', quindi l'hai configurato, se è così sono fuori di idee ... In bocca al lupo – Gab

+0

nel mio caso la versione era un intervallo [12.1 12.2) e la cache dei metadati è stata impostata su 24 ore in modo da verificare ogni giorno una nuova versione al primo build – mzzzzb

11

E 'forse per usare il flag -o,--offline "Work offline" di evitare che.

Ti piace questa:

maven compile -o

Problemi correlati