Dlaczego Maven za każdym razem pobiera plik maven-metadata.xml?

116

Poniżej znajduje się błąd, który zwykle otrzymuję, gdy moje połączenie internetowe jest niestabilne podczas próby zbudowania aplikacji internetowej za pomocą mavena.

Moje pytanie brzmi: dlaczego maven zawsze musi pobierać za każdym razem, gdy ta sama aplikacja została zbudowana wcześniej.

Co może być nie tak w mojej konfiguracji, co powoduje, że maven pobiera za każdym razem?

Poniżej znajduje się błąd, który pojawia się, gdy próbuję budować 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)
kwarki
źródło
2
Dostęp do metadanych w przypadku SNAPSHOTa jest niezbędny, aby Maven był informowany o nowo utworzonych SNAPSHOTach itp.
khmarbaise
7
Nie wiem dlaczego, ale możesz tego uniknąć, używając opcji -o, takiej jakmvn clean install -o
ant
W rzeczywistości błąd powodujący niepowodzenie kompilacji to „Błąd podczas tworzenia WAR: wymagany jest atrybut webxml (lub istniejący WEB-INF / web.xml, jeśli jest wykonywany w trybie aktualizacji)”. Więc powinieneś to naprawić. Nie mogę sobie wyobrazić, że jest to związane z Twoim połączeniem internetowym. Ostrzeżenia dotyczące rozwiązywania zależności są tylko takie: ostrzeżenia. Nie są ostateczną przyczyną niepowodzenia kompilacji.
Frans
Być może możesz wyjaśnić swoje pytanie, ponieważ wydaje się, że masz dwa pytania: 1) Dlaczego moja kompilacja nie działa? 2) Dlaczego maven próbuje pobrać metadane? odpowiedź użytkownika944849 to długa droga do odpowiedzi 2). Jeśli to odpowiada na twoje pytanie, powinieneś to zaakceptować.
Frans
Aktualizacja metadanych migawkę można uniknąć stosując -nsu, --no-snapshot-updatesopcja zmvn
Janaka Bandara

Odpowiedzi:

127

Poszukaj elementu w swoim settings.xml(lub być może w POM nadrzędnym lub korporacyjnym) <repositories>. Będzie wyglądać jak poniżej.

<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>

Zwróć uwagę na <updatePolicy>element. Przykład mówi Mavenowi, aby skontaktował się ze zdalnym repozytorium (w moim przypadku Nexus, Maven Central, jeśli nie używasz własnego zdalnego repozytorium) za każdym razem, gdy Maven musi pobrać artefakt migawki podczas kompilacji, sprawdzając, czy jest nowsza kopia. Do tego wymagane są metadane. Jeśli istnieje nowsza kopia, Maven pobiera ją do lokalnego repozytorium.

W tym przykładzie dla wydań zasada jest dailytaka, że ​​będzie sprawdzana podczas pierwszej kompilacji danego dnia. neverjest również prawidłową opcją, jak opisano w dokumentacji ustawień Mavena .

Wtyczki są rozwiązywane osobno. Możesz mieć również skonfigurowane repozytoria, z różnymi zasadami aktualizacji, jeśli chcesz.

<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>

Ktoś inny wspomniał o tej -oopcji. Jeśli tego używasz, Maven działa w trybie „offline”. Wie, że ma tylko lokalne repozytorium i nie skontaktuje się ze zdalnym repozytorium, aby odświeżyć artefakty, bez względu na używane zasady aktualizacji.

user944849
źródło
2
Pytanie brzmi: dlaczego nie zawsze jest „nigdy” (a moim zdaniem powinno tak być)? Dlaczego potrzebujesz aktualizacji codziennie lub zawsze?
Leon
@Leon W połowie cyklu rozwoju Twój projekt może mieć zależności typu `` -SNAPSHOT '', dla których możesz chcieć zawsze wybrać najnowszą zbudowaną wersję - przynajmniej w systemie CI, który prawdopodobnie byś chciał, programista może mieć inne preferencje - stabilność kompilacji handlu vs pobieranie najnowszych zmian. To, czego dokumentacja maven (co charakterystyczne, niestety) nie jest jasne, to domyślne wartości tych wartości, jeśli nic nie jest ustawione.
Ed Randall,
1
Najlepszą praktyką jest to, że raz wydany artefakt nigdy się nie zmienia, więc <updatePolicy> nigdy </updatePolicy> powinno być dla nich odpowiednie.
Ed Randall,
Ale co, jeśli zaktualizujesz zależności POM do nowej wersji? Czy nigdy nie zostanie zaktualizowany?
Philip Rego
1
@PhilipRego - aktualizacjaPolicy dotyczy każdego artefaktu. Jeśli zmienisz numer wersji lub identyfikator grupy / artefaktu, będzie to inny artefakt. Jeśli updatePolicy ma wartość „nigdy”, artefakt zostanie pobrany raz, chyba że odświeżenie zostanie wymuszone -Ulub artefakt zostanie usunięty z lokalnego repozytorium i trzeba będzie go pobrać ponownie.
user944849
31

Możliwe jest użycie flagi, -o,--offline "Work offline"aby temu zapobiec.

Lubię to:

maven compile -o

jfc
źródło
Uważam, że to powinna być prawidłowa odpowiedź, ponieważ możesz po prostu wywołać to polecenie, gdy twoje połączenie internetowe jest niestabilne. I o to pytano ...
Więc S
13

Przypuszczam, że ponieważ nie określiłeś wersji wtyczki, więc uruchamia pobieranie powiązanych metadanych w celu uzyskania ostatniej.

Czy w przeciwnym razie próbowałeś wymusić użycie lokalnego repozytorium za pomocą -o?

Gadanina
źródło
Jak więc określić wersję wtyczki? Jestem pewien, że mam wersję ustawioną w POM ... czy możesz być bardziej szczegółowy?
kwarki
cóż, jeśli masz versionelement wewnątrz pluginelementu, to rzeczywiście go skonfigurowałeś, jeśli tak, nie mam pomysłów ... Powodzenia
Gab
w moim przypadku wersja była z zakresu [12.1 12.2), a pamięć podręczna metadanych została ustawiona na 24 godziny, więc sprawdzałaby dostępność nowszej wersji przy pierwszej kompilacji każdego dnia
mzzzzb
A co z domyślnymi wtyczkami? takie jak maven-surefire-common, których nie określiłem?
yegeniy
ich wersja jest ustalona dla danego wydania mavena, ale możesz wymusić inną za pomocą pluginManagementsekcji
Gab
0

Nie uczyłem się jeszcze, kiedy Maven wykonuje które wyszukiwanie, ale aby uzyskać stabilne i odtwarzalne kompilacje, zdecydowanie zalecam, aby nie uzyskiwać bezpośredniego dostępu do repozytoriów Maven, ale użyć Menedżera repozytoriów Maven, takiego jak Nexus.

Oto samouczek, jak skonfigurować plik ustawień:

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

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

Kolor brązowofioletowy
źródło
@acdcjunior, jak powiedziałem, jeszcze tego nie studiowałem. Ale użycie lokalnego Maven Repository Manager rozwiąże również większość tych problemów (jeśli Maven sprawdzi metadane, uzyska dostęp tylko do twojego Maven Repository Manager)
Puce
1
IMHO menedżer repozytoriów jest przydatny tylko w organizacji, aby uniknąć zbędnego pobierania, a zwłaszcza do wdrażania artefaktów specyficznych dla tej organizacji (takich jak nadrzędne pompy i moduły wewnętrzne). W przeciwnym razie po co dodawać dodatkowe lustro, skoro masz już lokalne?
Gab
@Puce Nie wiem, jak to rozwiązałoby problem. Jeśli nie chcesz, aby maven w ogóle sprawdzał metadane w sieci, nie ma znaczenia, czy sprawdza to w Internecie, czy w menedżerze repozytoriów intranetu.
eis
@eis to powinno pomóc, jeśli "połączenie internetowe jest niestabilne" lub jeśli jeden z serwerów repozytorium jest obecnie niedostępny, ponieważ masz dostęp tylko do menedżera repozytorium maven w twojej sieci LAN.
Puce
@Gap Podczas gdy menedżerowie repozytoriów są szczególnie przydatni w organizacji z powodów, o których wspomniałeś, menedżer repozytoriów jest również ważny, aby uzyskać stabilne i odtwarzalne kompilacje, do czego zwykle dążę, nawet jeśli obecnie jestem jedynym programistą w projekcie. Zapewnia, że ​​mogę wyczyścić moje lokalne repozytorium i nadal mogę odtworzyć wszystkie kompilacje, a inni programiści mogą łatwo dołączyć do projektu. Zapewniam to z Jenkinsem, który czasami działa również lokalnie, uzyskuje również dostęp do menedżera repozytoriów, a także pomaga w wydaniu moich projektów -> 2 użytkowników uzyskujących dostęp do menedżera repozytoriów: Jenkins i ja
Puce
0

Maven robi to, ponieważ twoja zależność jest w wersji SNAPSHOT, a maven nie ma możliwości wykrycia jakichkolwiek zmian wprowadzonych w tej wersji migawki w repozytorium. Uwolnij swój artefakt i zmień wersję w pom.xml na tę wersję, a maven nie będzie już pobierać pliku metadanych.

Maskować
źródło