Чому 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
мураха

Власне, помилка, на яку збирається збірка, - це "Помилка збирання WAR: атрибут webxml потрібен (або попередньо існуючий WEB-INF / web.xml, якщо виконується в режимі оновлення)". Тож вам слід це виправити. Я не можу уявити, що це пов'язано з вашим інтернет-з'єднанням. Попередження щодо вирішення залежності - це саме те, що: попередження. Вони не є кінцевою причиною вашої збірки.
Франс

Можливо, ви можете уточнити своє запитання, оскільки у вас, здається, є два питання: 1) Чому моя збірка не працює? 2) Чому Maven намагається завантажити метадані? Відповідь user944849 проходить довгий шлях до відповіді 2). Якщо це відповідає на ваше запитання, ви повинні прийняти його.
Франс

Оновлення метаданих знімка можна уникнути за допомогою -nsu, --no-snapshot-updatesопція зmvn
Janaka Bandara

Відповіді:


127

Подивіться у своєму 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 - оновленняPolicy застосовується за артефактом. Якщо ви змінили номер версії або ідентифікатор групи / артефактів, це інший артефакт. Якщо updatePolicy "ніколи", артефакт буде завантажено один раз, якщо тільки оновлення не примушене -Uабо артефакт буде вилучено з локального репо, і тому його потрібно повторно завантажити.
користувач944849

31

Можливо, використовувати прапор, -o,--offline "Work offline"щоб запобігти цьому.

Подобається це:

maven compile -o


Я вважаю, що це має бути правильна відповідь, тому що ви можете просто зателефонувати в цю команду, коли ваше інтернет-з'єднання є непоганим. І ось про що питали ...
Так S

13

Я думаю, тому що ви не вказали версію плагіна, тому це запускає завантаження пов'язаних метаданих, щоб отримати останню.

Інакше ви намагалися примусити локальне використання репо, використовуючи -o?


То як же вказати версію плагіна? Я впевнений, що у мене є версія встановленої в POM ... Ви можете бути більш конкретними?
кварки

добре, якщо у вас є versionелемент всередині pluginелемента, то ви його справді налаштували, якщо так, я не в ідеях ... Удачі
Габ

у моєму випадку версія була діапазоном [12.1 12.2), а кеш метаданих було встановлено на 24 години, щоб перевірити наявність нової версії при першому складанні кожного дня
mzzzzb

Що щодо плагінів за замовчуванням? наприклад maven-surefire-common, що я не вказав?
Єгеній

їх версія встановлена ​​для даного випуску Maven, але ви можете застосувати інший, використовуючи pluginManagementрозділ
Gab

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)
Пуце,

1
IMHO-менеджер РЕПО корисний лише всередині організації, щоб уникнути зайвого завантаження та, особливо, для розгортання артефактів, характерних для цієї організації (наприклад, батьківські тані та внутрішні модулі). Інакше навіщо додавати додаткове дзеркало, як ви вже маєте місцеве?
Габ

@Puce Я не бачу, як це вирішило б проблему. Якщо ви не хочете, щоб Maven взагалі перевіряв метадані по всій мережі, це не має значення, чи перевіряється це в Інтернеті чи у менеджера репо-інтранет.
eis

@eis це має допомогти, якщо "підключення до Інтернету є невмілим" або якщо один із серверів репозиторію наразі недоступний, оскільки ви маєте доступ лише до менеджера сховищ Maven у вашій локальній мережі.
Пуче

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

0

Maven робить це тому, що ваша залежність є у версії SNAPSHOT, і maven не має можливості виявити будь-які зміни, внесені до цієї версії знімка в сховищі. Відпустіть свій артефакт і змініть версію в pom.xml на цю версію, і maven більше не буде отримувати файл метаданих.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.