Maven использует неверное местоположение для загрузки плагина pom

Question

(Этот вопрос также задается в списке рассылки пользователей Maven)

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

(История может быть немного длинной)

Я использую Nexus 1.8.0 в качестве менеджера репозитория нашей компании. Я использую его в качестве прокси внешнего репо и хостинга нашего собственного репозитория. В Nexus есть много хранилищ. У меня есть одна группа репозиториев (назовем это PUBLIC ), которая группирует все публичные репозитории, включая maven central, codehaus и т. Д. Существует еще одна группа хранилищ (назовем ее EXT ), в которую мы помещаем сторонние артефакты.

В нашем проекте мы использовали org.codehaus.mojo:native2ascii-maven-plugin. Из-за ошибки в то время, вместо использования общедоступного org.codehaus.mojo:native2ascii-maven-plugin:1.0-alpha-1, я исправил ошибку и развернул ее в нашем репозитории EXT и назвал ее org.codehaus.mojo:native2ascii-maven-plugin:1.0-alpha-1.1 (то есть использовал новый номер версии 1.0-alpha-1.1 вместо 1.0-alpha-1)

Это нормально работает уже несколько лет.

Однако недавно новый разработчик пытается получить код и собрать его, используя Maven 2.2.1. Произошли странные вещи: сборка не удалась. Проверяя результат чистой установки mvn -X, он утверждает, что POM native2ascii-maven-plugin:1.0-alpha-1.1 не может быть загружен из PUBLIC , поэтому он будет использовать emtpy POM по умолчанию, что вызывает проблему сборки.

Проверяя локальный репозиторий, я обнаружил, что был загружен только JAR-файл native2ascii-maven-plugin:1.0-alpha-1.1. Я уверен, что в PUBLIC репозитории нет native2ascii-maven-plugin:1.0-alpha-1.1, а SHA JAR совпадает с native2ascii-maven-plugin:1.0-alpha-1.1 в EXT . Кажется, что Maven способен правильно загрузить JAR из репозитория EXT , но когда он пытается загрузить POM впоследствии, Maven ошибочно считает, что его следует загрузить из PUBLIC . Поскольку PUBLIC не содержит 1.0-alpha-1.1, Maven предполагает, что POM отсутствует.

В моем файле settings.xml задано репо EXT до PUBLIC . Что еще более странно, я пытался заблокировать доступ в Nexus для native2ascii-maven-plugin из PUBLIC . Maven, вместо получения POM из репозитория EXT , он получает напрямую из central . Наконец, я добавляю PUBLIC в качестве зеркала для central , и Maven может строить правильно, потому что EXT является единственным репо, содержащим native2ascii-maven-plugin. Maven, похоже, пытается загрузить POM из каждого репозитория, который содержит native2ascii-maven-plugin несмотря на номер версии, кроме EXT

Я просто не могу понять, почему это произойдет. Это использовалось в течение многих лет, и это было хорошо даже несколько недель назад (у меня есть другие новые разработчики, которые могут правильно загрузить плагин, несколько недель назад). Кто-нибудь может подсказать мне возможную причину проблемы? Я ничего не изменил в своем репо и не изменил версию Maven. Почему поведение загрузки Maven внезапно изменилось?

Answer 1

Сложно сказать.

Сначала моя теория о том, почему это больше не работает. Я предполагаю, что это «работало годами», потому что когда-то это работало, а потом все было в вашем локальном хранилище (<home>/.m2/repository). Позже что-то сломалось, но вы никогда не заметили, потому что у вас все было локально. У нового разработчика не было заполненного локального репозитория, поэтому при первом сборке у него возникали сбои.

Теперь мое предложение, которое может не сработать для вас. При использовании Nexus я думаю, что лучше всего создать единый «групповой» репозиторий, который связывает все остальные репозитории, и настроить группу так, чтобы упорядочить приоритет связанных репозиториев. Так что для вас, в группе, вы должны сначала перечислить EXT, а затем PUBLIC. Ваши POM и / или настройки будут ссылаться только на репозиторий групп. Это может просто дублировать то, что вы уже делаете другими способами, но, по крайней мере, это перемещает правила упорядочения в Nexus. Я бы переименовал ваш локальный репозиторий (чтобы вы могли вернуться обратно в случае необходимости) и попытался бы перестроить, чтобы увидеть, все ли разрешается правильно.

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

Answer 2

Наконец мне удалось выяснить «причину» проблемы.Это по моей вине в сочетании с еще неизвестным поведением Maven.Я добавляю это в качестве ответа, чтобы облегчить будущую ссылку для других людей.

Ключевой проблемой для них является то, что я пропустил версию плагина для этого конкретного проекта (я поставил соответствующий модуль управления плагинами для других проектов и другие плагины для этого проекта... Интересно, почему я сделал эту ошибку на этот раз?)

Способ воспроизвести проблему:

1. Отдельный репозиторий для хранения плагина (в моем случае, org.codehaus.mojo:native2ascii-maven-plugin:1.0-alpha-1.1)

2. В проекте POM добавьте плагин, без версии.Например,

   <plugins>
       <plugin>
           <groupId>org.codehaus.mojo</groupId>
           <artifactId>native2ascii-maven-plugin</artifactId>
       <plugin>
   </plugins>
   

3. в файле settings.xml, избегайте определения зеркал (т. Е. Файл settings.xml содержит только список репозиториев и pluginRepositories)

При такой настройкесначала очистите локальный репозиторий.Тогда постройте проект.После сборки проверьте каталог в локальном хранилище на наличие этого плагина (в моем случае .m2\repository\org\codehaus\mojo\native2ascii-maven-plugin\1.0-alpha-1.1), вы найдете только подарки JAR без соответствующего POM.(Вызванный Maven успешно получает JAR плагина, соответствующий pluginRepositories в файле settings.xml, но пытается получить POM из странного местоположения)

При той же настройке поместите версию в проект POM, очистителокальное репо и строить заново.Теперь все в порядке.

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

Причина такого поведения Maven до сих пор неизвестна, но по крайней мере в «правильном» POM (с правильно объявленной версией плагина) Maven работает нормально.Я подниму это как вопрос для Maven.

Answer 3

Вы упомянули, что используете maven 2.2.1, и я могу только попросить вас дважды проверить, у нас было странное поведение, касающееся загрузки jar-файлов из внутреннего репо, которое было вызвано обновлением OSX Lion, которое поставляется с maven3.Наше исправление состояло в том, чтобы повторно развернуть затронутый проект.

Answer 4

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

Это нормально работает уже несколько лет.

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

Все хорошо несколько месяцев назад (потому что я перенес наш CI-сервер, и у меня есть чистый env для сборки, и все в порядке).

Интересно. Таким образом, моя теория заключается в том, чтобы пойти и убедиться, что новый разработчик настроен правильно - что файл settings.xml находится на месте и читается (у меня были случаи, что settings.xml ТАМ, но неверно место!). Это простой, но Maven не перестает работать, если нет файла settings.xml, он просто использует значение по умолчанию, при котором вы можете видеть призраков.