Pourquoi Maven télécharge-t-il le fichier maven-metadata.xml à chaque fois?

116

Vous trouverez ci-dessous l'erreur que j'obtiens généralement lorsque ma connexion Internet est faible lorsque je tente de créer une application Web avec maven.

Ma question est la suivante: pourquoi maven doit-il toujours télécharger à chaque fois que la même application a été créée plus tôt.

Quel pourrait être le problème dans ma configuration qui oblige maven à télécharger à chaque fois?

Voici une erreur que j'obtiens lorsque j'essaye de créer hors ligne: 

[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)
java maven maven-3 maven-metadata quarks
la source
2
L'accès aux métadonnées en cas de SNAPSHOT est nécessaire pour informer Maven des nouveaux SNAPSHOT, etc.
khmarbaise
7
Je ne sais pas pourquoi mais vous pouvez éviter cela en utilisant l'option -o comme mvn clean install -o
ant
En fait, l'erreur sur laquelle la compilation échoue est "Erreur lors de l'assemblage de WAR: l'attribut webxml est requis (ou WEB-INF / web.xml préexistant si l'exécution en mode mise à jour)". Vous devriez donc résoudre ce problème. Je ne peux pas imaginer que cela soit lié à votre connexion Internet. Les avertissements de résolution de dépendance ne sont que cela: des avertissements. Ils ne sont pas la cause ultime de l'échec de votre build.
Frans
Peut-être pouvez-vous clarifier votre question car vous semblez avoir deux questions: 1) Pourquoi ma construction échoue-t-elle? 2) Pourquoi maven essaie-t-il de télécharger des métadonnées? La réponse de user944849 va un long chemin à la réponse 2). Si cela répond à votre question, vous devez l'accepter.
Frans
La mise à jour des métadonnées des instantanés peut être évitée en utilisant -nsu , --no-snapshot-updatesoption avecmvn
Janaka Bandara

Réponses:

127

Recherchez settings.xmll' <repositories>élément dans votre (ou, éventuellement, le POM parent ou société parent de votre projet) . Cela ressemblera à quelque chose comme ci-dessous.

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

Notez l' <updatePolicy>élément. L'exemple indique à Maven de contacter le référentiel distant (Nexus dans mon cas, Maven Central si vous n'utilisez pas votre propre référentiel distant) chaque fois que Maven a besoin de récupérer un artefact d'instantané pendant une compilation, en vérifiant s'il existe une copie plus récente. Les métadonnées sont nécessaires pour cela. S'il existe une copie plus récente, Maven la télécharge dans votre dépôt local.

Dans l'exemple, pour les versions, la politique est de dailyvérifier lors de votre première compilation de la journée. neverest également une option valide, comme décrit dans la documentation sur les paramètres Maven .

Les plugins sont résolus séparément. Vous pouvez également configurer des référentiels pour ceux-ci, avec des politiques de mise à jour différentes si vous le souhaitez.

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

Quelqu'un d'autre a mentionné le -o option. Si vous utilisez cela, Maven s'exécute en mode «hors ligne». Il sait qu'il n'a qu'un dépôt local et qu'il ne contactera pas le dépôt distant pour actualiser les artefacts, quelles que soient les stratégies de mise à jour que vous utilisez.

user944849
la source
2
La question est: pourquoi n'est-il pas toujours «jamais» (ce que je pense que cela devrait être)? Pourquoi avez-vous besoin d'une mise à jour quotidienne ou permanente?
Leon
@Leon Au milieu du cycle de développement, votre projet peut avoir des dépendances `` -SNAPSHOT '' pour lesquelles vous voudrez peut-être toujours choisir la dernière version construite - au moins, sur un système CI que vous auriez probablement, un développeur pourrait avoir des préférences différentes - stabilité de la construction commerciale vs obtenir les derniers changements. Ce que les documents maven (de manière caractéristique, malheureusement) ne parviennent pas à préciser, ce sont les valeurs par défaut pour ces derniers si rien n'est défini.
Ed Randall
1
La meilleure pratique est qu'une fois publié, un artefact ne change jamais, donc <updatePolicy> jamais </updatePolicy> devrait être approprié pour eux.
Ed Randall
Mais que faire si vous mettez à jour vos dépendances POM vers une nouvelle version? Ne sera-t-il jamais mis à jour?
Philip Rego
1
@PhilipRego - la updatePolicy s'applique par artefact. Si vous modifiez un numéro de version ou un ID de groupe / artefact, il s'agit d'un artefact différent. Si updatePolicy est «jamais», l'artefact sera téléchargé une fois, à moins que l'actualisation ne soit forcée avec -Uou que l'artefact soit supprimé du dépôt local et doive donc être retéléchargé.
user944849
31

Il est possible d'utiliser le drapeau -o,--offline "Work offline" pour éviter cela.

Comme ça:

maven compile -o

jfc
la source
Je pense que cela devrait être la bonne réponse, car vous pouvez simplement appeler cette commande lorsque votre connexion Internet est flanquée. Et c'est ce qui a été demandé ...
Donc S
13

Je suppose que parce que vous n'avez pas spécifié la version du plugin, cela déclenche le téléchargement des métadonnées associées afin d'obtenir la dernière.

Sinon, avez-vous essayé de forcer l'utilisation du dépôt local en utilisant -o?

Gab
la source
Alors, comment spécifiez-vous la version du plugin? Je suis sûr que la version est définie dans le POM ... pouvez-vous être plus précis?
quarks
Eh bien, si vous avez un versionélément à l'intérieur de l' pluginélément, vous l'avez en effet configuré, si c'est le cas, je n'ai plus d'idées ... Bonne chance
Gab
dans mon cas, la version était une plage [12.1 12.2) et le cache de métadonnées était défini sur 24 heures afin de vérifier la
présence
Qu'en est-il des plugins par défaut? tels que maven-surefire-common, que je n'ai pas spécifié?
yegeniy
leur version est corrigée pour une version de maven donnée mais vous pouvez en forcer une différente en utilisant la pluginManagementsection
Gab
0

Je n'ai pas encore étudié, quand Maven fait quelle recherche, mais pour obtenir des constructions stables et reproductibles, je recommande fortement de ne pas accéder directement aux référentiels Maven mais d'utiliser un gestionnaire de référentiels Maven tel que Nexus.

Voici le tutoriel pour configurer votre fichier de paramètres:

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

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

Puce
la source
@acdcjunior comme je l'ai dit, je n'ai pas encore étudié cela. Mais l'utilisation d'un Maven Repository Manager local résoudra également la plupart de ces problèmes (si Maven vérifie les métadonnées, il n'accédera qu'à votre Maven Repository Manager)
Puce
1
À mon humble avis, un gestionnaire de repo n'est utile qu'à l'intérieur d'une organisation pour éviter les téléchargements redondants et en particulier pour déployer des artefacts spécifiques à cette organisation (comme les poms parents et les modules internes). Sinon pourquoi ajouter un miroir supplémentaire car vous avez déjà le miroir local?
Gab
@Puce Je ne vois pas comment cela résoudrait le problème. Si vous ne voulez pas du tout que maven vérifie les métadonnées sur le réseau, peu importe qu'il vérifie depuis Internet ou depuis le gestionnaire de dépôt intranet.
eis
@eis cela devrait aider si la "connexion Internet est flanquée" ou si l'un des serveurs de référentiel n'est actuellement pas disponible, car vous n'accédez qu'au gestionnaire de référentiel maven dans votre LAN.
Puce
@Gap alors que les gestionnaires de repo sont particulièrement utiles dans une organisation pour les raisons que vous avez mentionnées, un gestionnaire de repo est également important pour obtenir des builds stables et reproductibles, ce que je vise généralement même si je suis actuellement le seul développeur du projet. Cela garantit que je peux effacer mon dépôt local et que je suis toujours capable de reproduire toutes les versions et que d'autres développeurs pourraient facilement rejoindre le projet. Je l'assure avec Jenkins, qui fonctionne parfois aussi localement, accède également au gestionnaire de dépôt et aide également à libérer mes projets -> 2 utilisateurs accédant au gestionnaire de dépôt: Jenkins et moi
Puce
0

Maven fait cela car votre dépendance est dans une version SNAPSHOT et maven n'a aucun moyen de détecter les modifications apportées à cette version de snapshot dans le référentiel. Libérez votre artefact et remplacez la version de pom.xml par cette version et maven ne récupérera plus le fichier de métadonnées.

Masquer
la source