¿Por qué Maven descarga maven-metadata.xml cada vez?

116

A continuación se muestra el error que generalmente obtengo cuando mi conexión a Internet es irregular cuando intento crear una aplicación web con maven.

Mi pregunta es por qué Maven siempre tiene que descargar cada vez que la misma aplicación se ha creado antes.

¿Qué podría estar mal en mi configuración que hace que maven se descargue cada vez?

A continuación se muestra un error que obtengo cuando intento compilar sin conexión:

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

— quarks
fuente

2

El acceso a los metadatos en caso de SNAPSHOT es necesario para informar a Maven sobre SNAPSHOT recién creados, etc.

— khmarbaise

7

No sé por qué, pero puede evitar esto usando la opción -o comomvn clean install -o

— hormiga

En realidad, el error en el que falla la compilación es "Error al ensamblar WAR: se requiere el atributo webxml (o WEB-INF / web.xml preexistente si se ejecuta en modo de actualización)". Entonces deberías arreglar eso. No puedo imaginar que esté relacionado con su conexión a Internet. Las advertencias de resolución de dependencia son solo eso: advertencias. No son la causa principal de su falla en la construcción.

— Frans

Quizás pueda aclarar su pregunta ya que parece tener dos preguntas: 1) ¿Por qué está fallando mi construcción? 2) ¿Por qué maven intenta descargar metadatos? La respuesta de user944849 es muy útil para responder 2). Si eso responde a su pregunta, debe aceptarla.

— Frans

La actualización de metadatos de instantáneas se puede evitar usando -nsu, --no-snapshot-updatesopción conmvn

— Janaka Bandara

127

Busque en su settings.xml(o posiblemente el POM principal de su proyecto o el padre corporativo) el <repositories>elemento. Se verá algo parecido al siguiente.

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

Tenga en cuenta el <updatePolicy>elemento. El ejemplo le dice a Maven que se comunique con el repositorio remoto (Nexus en mi caso, Maven Central si no está usando su propio repositorio remoto) cada vez que Maven necesite recuperar un artefacto de instantánea durante una compilación, verificando si hay una copia más nueva. Los metadatos son necesarios para esto. Si hay una copia más reciente, Maven la descarga en su repositorio local.

En el ejemplo, para las versiones, la política es dailyque verificará durante su primera compilación del día. nevertambién es una opción válida, como se describe en los documentos de configuración de Maven .

Los complementos se resuelven por separado. También puede tener repositorios configurados para esos, con diferentes políticas de actualización si lo desea.

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

Alguien más mencionó la -oopción. Si lo usa, Maven se ejecuta en modo "sin conexión". Sabe que solo tiene un repositorio local y no se comunicará con el repositorio remoto para actualizar los artefactos, independientemente de las políticas de actualización que utilice.

— usuario944849
fuente

2

La pregunta es: ¿por qué no siempre es "nunca" (que creo que debería ser)? ¿Por qué necesitas una actualización diaria o siempre?

— León

@Leon Durante la mitad del ciclo de desarrollo, su proyecto puede tener dependencias '-SNAPSHOT' para las cuales es posible que desee elegir siempre la última versión construida; al menos, en un sistema de CI probablemente lo haría, un desarrollador podría tener una preferencia diferente: estabilidad de compilación comercial vs obtener los últimos cambios. Lo que los documentos de maven (de forma característica, desafortunadamente) no aclaran son los valores predeterminados para estos si no se establece nada.

— Ed Randall

1

La mejor práctica es que una vez liberado un artefacto nunca cambia, por lo que <updatePolicy> nunca </updatePolicy> debería ser apropiado para ellos.

— Ed Randall

Pero, ¿qué pasa si actualiza sus dependencias de POM a una nueva versión? ¿Nunca se actualizará?

— Philip Rego

1

@PhilipRego: updatePolicy se aplica por artefacto. Si cambia un número de versión o un ID de grupo / artefacto, es un artefacto diferente. Si updatePolicy es 'never', el artefacto se descargará una vez, a menos que se fuerce la actualización -Uo el artefacto se elimine del repositorio local y, por lo tanto, deba volver a descargarse.

— user944849

31

Posiblemente sea para usar la bandera -o,--offline "Work offline"para evitarlo.

Me gusta esto:

maven compile -o

— jfc
fuente

Creo que esta debería ser la respuesta correcta, porque simplemente puede llamar a este comando cuando su conexión a Internet es irregular. Y esto fue lo que se preguntó ...

— Entonces S

13

Supongo que debido a que no especificó la versión del complemento, se activa la descarga de metadatos asociados para obtener el último.

De lo contrario, ¿intentó forzar el uso del repositorio local usando -o?

— Charla
fuente

Entonces, ¿cómo se especifica la versión del complemento? Estoy seguro de que tengo una versión configurada en el POM ... ¿puede ser más específico?

— quarks

bueno, si tiene un versionelemento dentro del pluginelemento, entonces lo ha configurado, si es así, no tengo ideas ... Buena suerte

— Gab

en mi caso, la versión era un rango [12.1 12.2) y la caché de metadatos se configuró en 24 horas, por lo que buscaría una versión más nueva en la primera compilación cada día

— mzzzzb

¿Qué pasa con los complementos predeterminados? como maven-surefire-common, que no he especificado?

— yegeniy

su versión está corregida para una versión de maven determinada, pero puede forzar una diferente usando la pluginManagementsección

— Gab

0

No he estudiado todavía, cuando Maven hace qué búsqueda, pero para obtener compilaciones estables y reproducibles, recomiendo encarecidamente no acceder directamente a los repositorios de Maven, sino utilizar un administrador de repositorio de Maven como Nexus.

Aquí está el tutorial sobre cómo configurar su archivo de configuración:

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

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

— Pardo rojizo
fuente

@acdcjunior como dije, todavía no lo he estudiado. Pero el uso de un administrador de repositorio de Maven local también resolverá la mayoría de estos problemas (si Maven busca metadatos, solo accederá a su administrador de repositorio de Maven)

— Puce

1

En mi humilde opinión, un administrador de repositorios es útil solo dentro de una organización para evitar descargas redundantes y, en particular, para implementar artefactos específicos de esta organización (como poms principales y módulos internos). De lo contrario, ¿por qué agregar un espejo adicional si ya tiene el local?

— Gab

@Puce No veo cómo eso resolvería el problema. Si no desea que maven compruebe los metadatos en la red, no importa si los comprueba desde Internet o desde el administrador de repositorios de la intranet.

— EIS

@eis debería ayudar si la "conexión a Internet es de flanqueo" o si uno de los servidores del repositorio no está disponible actualmente, ya que solo está accediendo al administrador del repositorio maven en su LAN.

— Puce

@Gap, si bien los administradores de repositorios son particularmente útiles en una organización por las razones que mencionaste, un administrador de repositorios también es importante para obtener compilaciones estables y reproducibles, que es algo a lo que normalmente apunto incluso si actualmente soy el único desarrollador en el proyecto. Me asegura que puedo borrar mi repositorio local y aún puedo reproducir todas las compilaciones y que otros desarrolladores podrían unirse fácilmente al proyecto. Lo aseguro con Jenkins, que a veces también se ejecuta localmente, también accede al administrador de repositorios y también ayuda a lanzar mis proyectos -> 2 usuarios que acceden al administrador de repositorios: Jenkins y yo

— Puce

0

Maven hace esto porque su dependencia está en una versión SNAPSHOT y maven no tiene forma de detectar ningún cambio realizado en esa versión instantánea en el repositorio. Libera tu artefacto y cambia la versión en pom.xml a esa versión y maven ya no buscará el archivo de metadatos.

— Para enmascarar
fuente