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)

— 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

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