#java #maven-2 #plugins #build #build-process
#java #maven-2 #Плагины #сборка #процесс сборки
Вопрос:
Я только что потерял 2 часа времени из-за ошибки в maven-compiler-plugin версии v2.0.2, которая была исправлена в версии v2.3.2.
Очевидно, что если вы не укажете версию плагина компилятора Maven, Maven 2.2.1 просто предоставит вам версию v2.0.2.
В нашем проекте используется более 15 плагинов Maven. Некоторые из них мы хотим привязать к определенной версии, но большинство из них (например, плагин compiler) мы хотели бы обновить, не задумываясь об этом.
Есть ли способ сделать это автоматически с помощью Maven, или мы должны поручить кому-то неблагодарную задачу изучения возможных обновлений подключаемых модулей Maven каждый месяц, а затем изменять номера версий pluginManagement в нашем родительском POM?
Комментарии:
1. Это не применимо напрямую, но maven3 выдает предупреждение, когда вы не указываете номер версии для плагинов, указывая, что предупреждение предназначено для обратной совместимости.
2. @Jeremy Изменения, не имеющие обратной совместимости, будут внесены в Maven 3.1. Между тем, Maven 3.0 помогает вам исправить ваши pom.
Ответ №1:
Очевидно, что если вы не укажете версию плагина компилятора Maven, Maven 2.2.1 просто предоставит вам версию v2.0.2.
Да, начиная с Maven 2.0.9 (см. MNG-3395) версии основных и распространенных плагинов исправлены в super POM, а Maven отключил обнаружение версий плагинов ради воспроизводимости сборки.
В нашем проекте используется более 15 плагинов Maven. Некоторые из них мы хотим привязать к определенной версии, но большинство из них (например, плагин compiler) мы хотели бы обновить, не задумываясь об этом.
Как указывалось выше, это плохая идея. Вы просто не хотите, чтобы сборка maven внезапно начала завершаться сбоем из-за какого-либо обновления плагина. Другими словами, вы должны использовать фиксированные версии, а не делать этого — плохая практика. На самом деле, Maven 3.0 поощряет эту практику и предупреждает вас, если вы этого не сделаете. А в 3.1 вам нужно будет указать версию (см. MNG-1968).
Лично я использую плагин Maven Enforcer и его правило требовать версии плагинов для обеспечения соблюдения этой практики (что означает, что сборка завершится неудачей, если вы не заблокируете версии плагинов).
Есть ли способ сделать это автоматически с помощью Maven, или мы должны поручить кому-то неблагодарную задачу изучения возможных обновлений подключаемых модулей Maven каждый месяц, а затем изменять номера версий pluginManagement в нашем родительском POM?
Как и предлагалось, плагин Maven для версий имеет цели, позволяющие проверить, существуют ли более свежие версии плагинов, зависимостей и т.д. (и обратите внимание, что -cpu он устарел в Maven 3.0 и будет удален из будущих версий).
Но реальный вопрос в том, почему вы хотите всегда использовать конечные версии? ИМО, для этого нет веских причин, вам следует обновляться, только если есть что исправить («если это не сломано, не исправляйте это»).
Итог: используйте фиксированные версии плагинов и забудьте об автоматических обновлениях, диапазонах версий и т.д.
Комментарии:
1. 1 за это: ‘Лично я использую плагин Maven Enforcer и его правило требовать версии плагинов для обеспечения соблюдения этой практики (что означает, что сборка завершится неудачей, если вы не заблокируете версии плагинов).’
2. @javamonkey79: Это один из моих любимых плагинов. Я использую его во всех своих сборках.
3. Одна из возможных причин автоматического обновления может заключаться в ветке , которая затем проходит полный набор тестов, чтобы проверить, работает ли она так, как задумано. Затем эта информация полезна для оценки того, когда и нужно ли обновлять основную ветку, а также для предупреждения о проблемах в случае критического изменения.
Ответ №2:
Вы могли бы привязать что-то вроде versions-maven-plugin к вашей основной сборке, чтобы вы получали отчет о каждой сборке, показывающий, обновлены ли ваши плагины.
Смотрите по этой ссылке подробную информацию о том, как: Отображать обновления плагина
Если вы хотите пофантазировать, попросите ваш сервер CI запустить вывод вашей сборки maven с помощью скрипта для проверки [WARNING] записей журнала, которые сигнализируют о новых версиях, а затем уведомить соответствующих членов вашей команды по электронной почте или каким-либо другим уведомлением.
Комментарии:
1. Черт возьми … использую Maven более 2 лет, понятия не имел, что могу просто запустить mvn versions:display-plugin-updates и получить всю полезную информацию. Это все еще приходится делать вручную, но это действительно упрощает задачу. То же самое и для обычных зависимостей с версиями mvn:display-dependency-updates — спасибо.
Ответ №3:
Сегодня я во второй раз пишу это:
Попробуйте использовать -cpu флаг. Вывод из mvn -help :
usage: mvn [options] [<goal(s)>] [<phase(s)>]
Options:
-cpu,--check-plugin-updates Force upToDate check for any
relevant registered plugins
Комментарии:
1. Черт возьми, эта опция устарела в Maven 3.0.
Ответ №4:
Вы также можете использовать диапазоны версий в своих плагинах.
Комментарии:
1. Баааааааааааад практика, не делайте этого.
2. @Pascal: Забавно, что ты это говоришь. Что касается зависимостей, то наша команда вроде как согласилась, что это больше хлопот, чем того стоит. Но правильно ли использовать плагины, так ли это плохо? Это также вызывает у меня вопрос: если это плохая практика в целом, то каков ее вариант использования?
3. На мой взгляд, не существует допустимого варианта использования (и хотя Maven поддерживает диапазоны версий, я считаю, что это не поощряет их использование).
4. Теоретически, если бы люди придерживались стандартов управления версиями (таких как Apache), тогда можно было бы использовать разумный диапазон (например, до следующей младшей версии). Однако я думаю, что проблема заключается в несоблюдении стандартов. Тем не менее, я понимаю вашу точку зрения и не рекомендовал бы их в 99% всех случаев использования — я просто хотел бы, чтобы соблюдение надлежащего управления версиями было лучше, чтобы диапазоны могли быть более удобными.
5. На мой взгляд, самая большая проблема на самом деле заключается не в разрешении версии (это может сработать при соблюдении стандартов, как вы указали), проблема в том, что диапазоны версий могут вызвать нежелательные изменения поведения вашей сборки, и поиск таких проблем — это боль (вы не можете различать POMS, вы не можете легко вернуться в рабочее состояние). Диапазоны версий — это вход во врата ада.