Por que o Maven está baixando o maven-metadata.xml todas as vezes?

116

Abaixo está o erro que geralmente recebo quando minha conexão com a Internet falha ao tentar construir um aplicativo da web com o maven.

Minha pergunta é: por que o maven sempre precisa fazer o download sempre que o mesmo aplicativo foi criado anteriormente.

O que pode estar errado na minha configuração que faz o maven baixar todas as vezes?

Abaixo está um erro que recebo quando tento construir 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)
java maven maven-3 maven-metadata quarks
fonte
2
O acesso aos metadados em caso de SNAPSHOT é necessário para informar o Maven sobre SNAPSHOT recém-criado etc.
khmarbaise
7
Não sei por que, mas você pode evitar isso usando a opção -o comomvn clean install -o
formiga
Na verdade, o erro em que a construção falha é "Erro ao montar WAR: o atributo webxml é necessário (ou WEB-INF / web.xml pré-existente se estiver executando no modo de atualização)". Então você deve consertar isso. Não consigo imaginar que esteja relacionado à sua conexão de internet. Os avisos de resolução de dependência são apenas isso: avisos. Eles não são a causa final de sua falha de construção.
Frans
Talvez você possa esclarecer sua dúvida, já que parece ter duas perguntas: 1) Por que minha construção está falhando? 2) Por que o maven está tentando baixar metadados? a resposta do usuário944849 ajuda muito a responder 2). Se isso responde à sua pergunta, você deve aceitá-lo.
Frans
Atualização metadados instantâneo pode ser evitado usando -nsu, --no-snapshot-updatesopção commvn
Janaka Bandara

Respostas:

127

Procure o elemento no seu settings.xml(ou, possivelmente, no POM pai do projeto ou pai corporativo) <repositories>. Será algo parecido com o abaixo.

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

Observe o <updatePolicy>elemento. O exemplo diz ao Maven para contatar o repo remoto (Nexus no meu caso, Maven Central se você não estiver usando seu próprio repo remoto) a qualquer momento que o Maven precisar recuperar um artefato de instantâneo durante uma compilação, verificando se há uma cópia mais recente. Os metadados são necessários para isso. Se houver uma cópia mais recente, o Maven faz o download para seu repositório local.

No exemplo, para lançamentos, a política é dailyverificada durante sua primeira compilação do dia. nevertambém é uma opção válida, conforme descrito na documentação de configurações do Maven .

Os plug-ins são resolvidos separadamente. Você também pode ter repositórios configurados para eles, com políticas de atualização diferentes, se desejar.

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

Alguém mencionou a -oopção. Se você usar isso, o Maven será executado no modo "offline". Ele sabe que tem apenas um repo local e não contatará o repo remoto para atualizar os artefatos, independentemente das políticas de atualização usadas.

usuário944849
fonte
2
A questão é: por que nem sempre é "nunca" (o que eu acho que deveria ser)? Por que você precisa de atualização diária ou sempre?
Leon
@Leon Durante o ciclo de desenvolvimento intermediário, seu projeto pode ter dependências '-SNAPSHOT' para as quais você pode querer sempre escolher a versão compilada mais recente - pelo menos, em um sistema CI você provavelmente faria, um desenvolvedor pode ter uma preferência diferente - negociando estabilidade de compilação vs obter as alterações mais recentes. O que o maven docs (caracteristicamente, infelizmente) falha em deixar claro são os valores padrão para estes se nada for definido.
Ed Randall
1
A melhor prática é que, uma vez liberado, um artefato nunca muda, então <updatePolicy> nunca </updatePolicy> deve ser apropriado para eles.
Ed Randall
Mas e se você atualizar as dependências do POM para uma nova versão? Nunca será atualizado?
Philip Rego
1
@PhilipRego - a updatePolicy se aplica por artefato. Se você alterar um número de versão ou ID de grupo / artefato, esse é um artefato diferente. Se updatePolicy for 'nunca', o artefato será baixado uma vez, a menos que a atualização seja forçada -Uou o artefato seja removido do repositório local e, portanto, precise ser baixado novamente.
user944849
31

É possível usar a bandeira -o,--offline "Work offline"para evitar isso.

Como isso:

maven compile -o

JFC
fonte
Acredito que esta seja a resposta correta, pois você pode simplesmente chamar este comando quando sua conexão com a internet estiver fraca. E foi isso que foi perguntado ...
Então, S
13

Suponho que seja porque você não especificou a versão do plugin, então ele aciona o download dos metadados associados para obter o último.

Caso contrário, você tentou forçar o uso do repositório local usando -o?

Gab
fonte
Então, como você especifica a versão do plugin? Tenho certeza que tenho uma versão definida no POM ... você pode ser mais específico?
quarks de
bem, se você tem um versionelemento dentro do pluginelemento, então você realmente o configurou, se sim, estou sem ideias ... Boa sorte
Gab
no meu caso, a versão estava em um intervalo [12.1 12.2) e o cache de metadados foi configurado para 24 horas para que ele verificasse se há uma versão mais recente na primeira compilação a cada dia
mzzzzb
E quanto aos plug-ins padrão? como maven-surefire-common, que eu não especifiquei?
yegeniy,
a versão deles foi corrigida para uma determinada versão do maven, mas você pode forçar uma diferente usando a pluginManagementseção
Gab
0

Eu não estudei ainda, quando o Maven faz essa pesquisa, mas para obter compilações estáveis ​​e reproduzíveis, eu recomendo fortemente não acessar os repositórios Maven diretamente, mas usar um gerenciador de repositório Maven como o Nexus.

Aqui está o tutorial sobre como configurar seu arquivo de configurações:

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

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

Puce
fonte
@acdcjunior como eu disse, ainda não estudei isso. Mas usar um Maven Repository Manager local também resolverá a maioria desses problemas (se o Maven verificar os metadados, ele só acessará seu Maven Repository Manager)
Puce
1
IMHO, um gerenciador de repositório, é útil apenas dentro de uma organização para evitar download redundante e, particularmente, para implantar artefatos específicos para essa organização (como poms pai e módulos internos). Caso contrário, por que adicionar um espelho adicional, já que você já tem o local?
Gab
@Puce Não vejo como isso resolveria o problema. Se você não deseja que o maven verifique os metadados na rede, não importa se ele verifica na Internet ou no gerenciador de repositório da intranet.
eis
@eis deve ajudar se a "conexão com a internet estiver fraca" ou se um dos servidores de repositório não estiver disponível no momento, já que você está acessando apenas o gerenciador de repositório maven em sua LAN.
Puce
@Gap embora os gerenciadores de repo sejam particularmente úteis em uma organização pelos motivos que você mencionou, um gerenciador de repo também é importante para obter compilações estáveis ​​e reproduzíveis, que é algo que geralmente busco, mesmo se atualmente sou o único desenvolvedor do projeto. Isso garante que eu possa limpar meu repositório local e ainda reproduzir todas as compilações e que outros desenvolvedores possam facilmente ingressar no projeto. Garanto isso com o Jenkins, que às vezes também é executado localmente, acessa o gerenciador de repo e também ajuda a liberar meus projetos -> 2 usuários acessando o gerenciador de repo: Jenkins e eu
Puce
0

O Maven faz isso porque sua dependência está em uma versão SNAPSHOT e o maven não tem como detectar nenhuma alteração feita nessa versão do instantâneo no repositório. Libere seu artefato e altere a versão em pom.xml para essa versão e o maven não irá mais buscar o arquivo de metadados.

Para mascarar
fonte