Почему Maven каждый раз загружает maven-metadata.xml?


116

Ниже приведена ошибка, которую я обычно получаю, когда мое интернет-соединение не работает при попытке создать веб-приложение с помощью maven.

Мой вопрос в том, почему maven всегда нужно загружать каждый раз, когда одно и то же приложение было создано ранее.

Что может быть не так в моей конфигурации, что заставляет maven загружаться каждый раз?

Ниже приведена ошибка, которую я получаю, когда пытаюсь собрать оффлайн:

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

2
Доступ к метаданным в случае необходимости SNAPSHOT для информирования Maven о вновь созданных SNAPSHOT и т. Д.
khmarbaise

7
Я не знаю почему, но вы можете избежать этого, используя параметр -o, напримерmvn clean install -o
ant

На самом деле ошибка, из-за которой происходит сбой сборки: «Ошибка сборки WAR: требуется атрибут webxml (или уже существующий WEB-INF / web.xml, если выполняется в режиме обновления)». Так что вы должны это исправить. Я не могу представить, что это связано с вашим интернет-соединением. Предупреждения о разрешении зависимостей - это всего лишь предупреждения. Они не являются основной причиной сбоя вашей сборки.
Frans

Возможно, вы сможете уточнить свой вопрос, поскольку у вас, похоже, есть два вопроса: 1) Почему моя сборка не работает? 2) Почему maven пытается загрузить метаданные? Ответ user944849 имеет большое значение для ответа 2). Если это ответ на ваш вопрос, вы должны принять его.
Frans

Обновление метаданных снимка можно избежать , используя -nsu, --no-snapshot-updatesвариант сmvn
Джанаке Бандары

Ответы:


128

Найдите элемент в своем settings.xml(или, возможно, родительском или корпоративном POM вашего проекта) <repositories>. Это будет выглядеть примерно так, как показано ниже.

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

Обратите внимание на <updatePolicy>элемент. Пример сообщает Maven о необходимости связываться с удаленным репозиторием (Nexus в моем случае, Maven Central, если вы не используете собственное удаленное репо) каждый раз, когда Maven необходимо получить артефакт моментального снимка во время сборки, проверяя, есть ли более новая копия. Для этого требуются метаданные. Если есть более новая копия, Maven загружает ее в ваше локальное хранилище.

В примере для выпусков политика такова, dailyчто они будут проверяться во время вашей первой сборки за день. neverтакже допустимый вариант, как описано в документации по настройкам Maven .

Плагины решаются отдельно. Для них также могут быть настроены репозитории с разными политиками обновления, если это необходимо.

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

Кто-то еще упомянул об этом -oварианте. Если вы его используете, Maven будет работать в автономном режиме. Он знает, что у него есть только локальное репо, и он не будет связываться с удаленным репо для обновления артефактов независимо от того, какие политики обновления вы используете.


2
Возникает вопрос: почему не всегда «никогда» (что, я думаю, должно быть)? Зачем нужно обновлять ежедневно или всегда?
Леон

@Leon В середине цикла разработки ваш проект может иметь зависимости '-SNAPSHOT', для которых вы, возможно, захотите всегда выбирать последнюю собранную версию - по крайней мере, в системе CI вы, вероятно, будете иметь другие предпочтения у разработчика - стабильность сборки торговли против получения последних изменений. Что в документации maven (что характерно, к сожалению) не проясняется, так это значения по умолчанию для них, если ничего не установлено.
Эд Рэндалл

1
Лучшая практика состоит в том, что после выпуска артефакт никогда не изменяется, поэтому <updatePolicy> никогда </updatePolicy> не должен подходить для них.
Эд Рэндалл

Но что, если вы обновите свои зависимости POM до новой версии? Никогда не обновится?
Филип Рего

1
@PhilipRego - updatePolicy применяется к каждому артефакту. Если вы измените номер версии или идентификатор группы / артефакта, это другой артефакт. Если updatePolicy имеет значение «never», то артефакт будет загружен один раз, если только не будет выполнено принудительное обновление -Uили артефакт не будет удален из локального репо и, следовательно, его не нужно будет повторно загрузить.
user944849

31

Возможно использование флага, -o,--offline "Work offline"чтобы предотвратить это.

Как это:

maven compile -o


Я считаю, что это должен быть правильный ответ, потому что вы можете просто вызвать эту команду, когда ваше интернет-соединение не работает. И вот о чем спросили ...
So S

13

Я полагаю, потому что вы не указали версию плагина, поэтому он запускает загрузку связанных метаданных, чтобы получить последнюю.

В противном случае вы пытались принудительно использовать локальное репо с помощью -o?


Так как же указать версию плагина? Я уверен, что у меня установлена ​​версия в POM ... не могли бы вы уточнить?
кварки

Хорошо, если у вас есть versionэлемент внутри pluginэлемента, то вы действительно настроили его, если так, у меня нет идей ... Удачи
Габ

в моем случае версия была диапазоном [12.1 12.2), а кеш метаданных был установлен на 24 часа, поэтому он будет проверять наличие более новой версии при первой сборке каждый день
mzzzzb

А как насчет плагинов по умолчанию? например maven-surefire-common, который я не указал?
yegeniy 09

их версия исправлена ​​для данного выпуска maven, но вы можете принудительно установить другую, используя pluginManagementраздел
Габ,

0

Я еще не изучал, когда Maven выполняет этот поиск, но для получения стабильных и воспроизводимых сборок я настоятельно рекомендую не обращаться к Maven Respositories напрямую, а использовать Maven Repository Manager, такой как Nexus.

Вот руководство по настройке файла настроек:

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

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


@acdcjunior, как я уже сказал, я еще не изучал это. Но использование локального диспетчера репозитория Maven также решит большинство этих проблем (если Maven проверяет метаданные, он будет обращаться только к вашему диспетчеру репозитория Maven)
Puce

1
IMHO, менеджер репо полезен только внутри организации, чтобы избежать избыточной загрузки и, в частности, для развертывания артефактов, специфичных для этой организации (например, родительских модулей и внутренних модулей). Иначе зачем добавлять дополнительное зеркало, если у вас уже есть локальное?
Габ

@Puce Я не понимаю, как это решит проблему. Если вы не хотите, чтобы maven вообще проверял метаданные в сети, не имеет значения, проверяет ли он из Интернета или из диспетчера репозитория интрасети.
eis

@eis это должно помочь, если "соединение с Интернетом не работает" или если один из серверов репозитория в настоящее время недоступен, поскольку вы обращаетесь только к менеджеру репозитория maven в своей локальной сети.
Puce

@Gap, хотя менеджеры репо особенно полезны в организации по причинам, о которых вы упомянули, менеджер репо также важен для получения стабильных и воспроизводимых сборок, к чему я обычно стремлюсь, даже если я в настоящее время единственный разработчик в проекте. Это гарантирует, что я могу стереть свое локальное репо и все еще могу воспроизвести все сборки, и что другие разработчики могут легко присоединиться к проекту. Я заверяю это с помощью Jenkins, который иногда также запускается локально, также обращается к менеджеру репо, а также помогает выпустить мои проекты -> 2 пользователя получают доступ к менеджеру репо: Дженкинс и я
Puce

0

Maven делает это, потому что ваша зависимость находится в версии SNAPSHOT, и maven не может обнаружить какие-либо изменения, внесенные в эту версию моментального снимка в репозитории. Освободите свой артефакт и измените версию в pom.xml на эту версию, и maven больше не будет получать файл метаданных.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.