Как я могу заставить Maven прекратить попытки проверки обновлений для артефактов из определенной группы из maven-central-repo?


126

Я работаю над довольно большим проектом Maven. У нас, вероятно, около 70 отдельных артефактов, которые примерно разделены на две библиотеки общего кода и, возможно, десять приложений, которые их используют. Все эти элементы находятся в пространстве имен com.mycompany.*.

В большинстве случаев мы работаем против сборок моментальных снимков. Итак, чтобы выполнить полную сборку приложения, я мог бы сначала собрать проекты библиотеки, чтобы они были установлены в моем локальном репозитории (как, скажем, mycompany-libname-2.4-SNAPSHOT.jar).

Проблема в том, что когда я затем собираю приложения. По какой-то причине Maven хочет проверить два основных общедоступных репозитория (maven-net-repo и java-net-repo) на предмет обновлений для всех mycompany-*-SNAPSHOT.jarартефактов. Конечно, их там нет, и все в конечном итоге возвращается к версиям, которые я только что построил в своем локальном репозитории, но я бы хотел, чтобы Maven прекратил это делать, потому что (а) это заставляет меня чувствовать себя плохим net.citizen для постоянной проверки этих репозиториев на предмет того, чего там никогда не будет, и (б) это добавляет некоторую ненужную и раздражающую сетевую задержку в мой процесс сборки.

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

Ответы:


34

Тег updatePolicy у меня не работал. Однако Rich Seller упомянул, что моментальные снимки в любом случае должны быть отключены, поэтому я посмотрел дальше и заметил, что дополнительный репозиторий, который я добавил в свой settings.xml, на самом деле вызывает проблему. Добавление раздела снимков в этот репозиторий в моем файле settings.xml помогло!

<repository>
    <id>jboss</id>
    <name>JBoss Repository</name>
    <url>http://repository.jboss.com/maven2</url>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
</repository>

Большое спасибо за ответ. В конечном итоге мне это помогло. У меня возникли проблемы с загрузкой моментальных снимков для одного из репозиториев. Загрузки висели даже при обновлении полиции ни разу. Теперь снимки не скачиваются, а я как раз и хотел.
wolfroma

163

Кроме того, вы можете использовать -oили --offlineв командной строке mvn, которая переведет maven в «автономный режим», поэтому он не будет проверять наличие обновлений. Вы получите предупреждение о том, что не можете получить зависимости, которых еще нет в вашем локальном репо, но ничего страшного.


8
Это также остановит maven от загрузки выпущенных зависимостей. Возможно, вам понадобится более новая версия выпущенной библиотеки, без проверки обновлений снимков
hobgoblin

2
Это ЯВНО не ответ на исходный вопрос! Как у него столько голосов за ??? ОП явно написал, что он пытался запустить maven в автономном режиме, но это не идеально для его цели!
Хонза Зидек

95

Что-то, что теперь доступно и в maven, это

mvn goal --no-snapshot-updates

или короче

mvn goal -nsu

3
На всякий случай кто-нибудь из SBT приземлится здесь: set offline := trueна сессии или offline := trueв build.sbt.
Опять

5
Кроме того, эта nsuопция не работает в версии 3.0.3 (см. MNG-5064 ). Чтобы использовать эту опцию надежно, вам может потребоваться обновление как минимум до версии 3.0.4 или версии 3.0.5
Ашутош Джиндал,

довольно лучший
AntJavaDev

32

Обновление: мне, наверное, следовало начать с этого, поскольку ваши проекты - снимки. Это часть семантики SNAPSHOT, которую Maven будет проверять на наличие обновлений при каждой сборке. Статус SNAPSHOT означает, что он нестабилен и может изменяться, поэтому обновления следует проверять. Однако стоит отметить, что Maven super POM конфигурирует централизованное отключение моментальных снимков, поэтому Maven никогда не должен проверять наличие обновлений для SNAPSHOTs на центральном сервере, если вы не переопределите это в своем собственном pom / settings.


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

В свой settings.xml вы должны добавить что-то вроде этого, чтобы настроить свой внутренний репозиторий как зеркало для центрального:

<mirrors>
  <mirror>
    <id>ibiblio.org</id>
    <name>ibiblio Mirror of http://repo1.maven.org/maven2/</name>
    <url>http://path/to/my/repository</url>
    <mirrorOf>central</mirrorOf>
  </mirror>
</mirrors>

Если вы используете менеджер репозитория, например Nexus, для своего внутреннего репозитория. Вы можете настроить репозиторий прокси для централизованного прокси, поэтому любые запросы, которые обычно поступают в центральный сервер, вместо этого отправляются в ваш репозиторий прокси (или группу репозитория, содержащую прокси), а последующие запросы кэшируются во внутреннем диспетчере репозитория. Вы даже можете установить для тайм-аута прокси-кеша значение -1, чтобы он никогда не запрашивал содержимое из центрального хранилища, которое уже находится в репозитории прокси.


Более простое решение, если вы работаете только с локальными репозиториями, - установить updatePolicy для центрального репозитория на «никогда», это означает, что Maven будет проверять только те артефакты, которых еще нет в локальном репозитории. Затем это можно при необходимости переопределить в командной строке, используя переключатель -U, чтобы Maven проверял наличие обновлений.

Вы должны настроить репозиторий (в вашем pom или профиле в settings.xml) следующим образом:

<repository>
  <id>central</id>
  <url>http://repo1.maven.org/maven2</url>
  <updatePolicy>never</updatePolicy>
</repository>

На самом деле у нас уже есть центральный репозиторий, но, конечно, мы не публикуем в него сборки моментальных снимков, поэтому, по-видимому, я все равно получу неудачные проверки обновлений с прокси / зеркалом на месте - я ищу способ получить Maven чтобы вообще не проверять наличие обновлений для этих артефактов.
Тим Гилберт,

1
Также стоит настроить логический репозиторий в центральном репозитории для ваших снимков. Это означает, что они могут быть разделены между вашими разработчиками, и вам не нужно создавать их все локально. После этого вы получите все преимущества SNAPSHOT, собирая изменения любых зависимостей SNAPSHOT, как только они будут отправлены в удаленный репозиторий.
Богатый продавец

Спасибо - флаг updatePolicy выглядит именно так, как я искал.
Тим Гилберт

1
Nexus также позволяет настраивать правила, предотвращающие любые запросы на внешние артефакты компании.
Брайан Фокс,

Приведенный здесь фрагмент XML уже устарел. updatePolicyЭлемент попадает под snapshotsили releasesэлемента. См .: maven.apache.org/settings.html
Джефф Эванс,

5

Очень просто :

В родительском файле Super POM или в файле setting.xml используйте

        <repository>
        <id>central</id>
        <releases>
            <updatePolicy>never</updatePolicy>
        </releases>
        <snapshots>
            <updatePolicy>never</updatePolicy>
        </snapshots>
        <url>http://repo1.maven.org/maven2</url>
        <layout>legacy</layout>
    </repository>

Это мои советы


0

У меня были проблемы, похожие на эту,

<repository>
    <id>java.net</id>
    <url>https://maven-repository.dev.java.net/nonav/repository</url>
    <layout>legacy</layout>
</repository>
<repository>
    <id>java.net2</id>
    <url>https://maven2-repository.dev.java.net/nonav/repository</url>
</repository>

Установка updatePolicy на «никогда» не сработала. Я решил удалить это репо. ps: я следил за этим руководством по веб-службам (кстати, вероятно, лучший учебник по ws для java)


1
Вы используете Intellij? Поскольку Intellij + Maven = игнорировать updatePolicy. См. Отчет об
Манав,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.