Используйте последнюю версию зависимости в Maven

1. обзор

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

В этом руководстве мы изучимhow to exploit the Versions Maven Plugin to keep our dependencies up-to-date.

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

2. Синтаксис диапазона версий Maven

Еще во времена Maven2 разработчики могли указывать диапазоны версий, в пределах которых артефакты будут обновляться без необходимости ручного вмешательства.

Этот синтаксис все еще действителен, используется в нескольких проектах и поэтому стоит знать:

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

2.1. Устаревший синтаксис

Maven2 также предоставил два специальных значения метаверсии для достижения результата:LATEST иRELEASE.

However, this legacy upgrade method was causing unpredictability where CI needed reproducibility. Следовательно,they’ve been deprecated and completely removed в Maven3:

Для воспроизводимых сборок Maven 3.x больше не поддерживает использование этих метаверсий в POM.

3. Плагин Versions Maven

Versions Maven Plugin - это де-факто стандартный способ управления версиями в настоящее время.

От высокоуровневых сравнений между удаленными репозиториями до низкоуровневой блокировки временных меток для версий SNAPSHOT, его обширный список целей позволяет нам позаботиться о каждом аспекте наших проектов, связанных с зависимостями.

Хотя многие из них выходят за рамки этого руководства, давайте подробнее рассмотрим те, которые помогут нам в процессе обновления.

3.1. Тестовый пример

Перед тем, как начать, давайте определим наш тестовый пример:

три релиза с жестко закодированной версией
один РЕЛИЗ с версией свойства, и
один SNAPSHOT


    
        commons-io
        commons-io
        2.3
    
    
        org.apache.commons
        commons-collections4
        4.0
    
    
        org.apache.commons
        commons-lang3
        3.0
    
    
        org.apache.commons
        commons-compress
        ${commons-compress-version}
    
    
        commons-beanutils
        commons-beanutils
        1.9.1-SNAPSHOT
    



    1.15

Наконец, давайте также исключим артефакт из процесса при определении плагина:


    
        
            org.codehaus.mojo
            versions-maven-plugin
            2.7
            
                
                    org.apache.commons:commons-collections4

4. Отображение доступных обновлений

Прежде всего,to simply know if and how we can update our project, the right tool for the job is versions:display-dependency-updates:

mvn versions:display-dependency-updates

Как видим,the process included every RELEASE version. It even included commons-collections4 since the exclusion in the configuration refers to the update process, and not to the discovery one.

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

5. Обновление зависимостей

При первом запуске обновления плагин создает резервную копиюpom.xml с именемpom.xml.versionsBackup.

Хотя каждая итерация будет изменятьpom.xml, файл резервной копии будет сохранять исходное состояние проекта до момента, когда пользователь зафиксирует (черезmvn versions:commit) или вернет (черезmvn versions:revert) проект весь процесс.

5.1. Преобразование SNAPSHOT в RELEASE

Иногда случается, что проект включает SNAPSHOT (версия, которая все еще находится в стадии разработки).

Мы можем использоватьversions:use-releases, чтобы проверить, был ли опубликован соответствующий RELEASE, и даже больше, чтобы одновременно преобразовать наш SNAPSHOT в этот RELEASE:

mvn versions:use-releases

5.2. Обновление до следующего релиза

We can port every non-SNAPSHOT dependency to its nearest version сversions:use-next-releases:

mvn versions:use-next-releases

Мы ясно видим, что плагин обновилcommons-io,commons-lang3 и дажеcommons-beanutils, который больше не является SNAPSHOT, до их следующей версии.

Что наиболее важно, он игнорировалcommons-collections4, который исключен в конфигурации плагина, иcommons-compress, номер версии которого указывается динамически через свойство.

5.3. Обновление до последней версии

Обновление всех зависимостей, не относящихся к SNAPSHOT, до последней версии работает таким же образом, просто меняя цель наversions:use-latest-releases:

mvn versions:use-latest-releases

6. Фильтрация нежелательных версий

In case we want to ignore certain versions, the plugin configuration can be tuned для динамической загрузки правил из внешнего файла:


    org.codehaus.mojo
    versions-maven-plugin
    2.7
    
        http://www.mycompany.com/maven-version-rules.xml

Примечательно, что<rulesUri> также может относиться к локальному файлу:

file:///home/andrea/maven-version-rules.xml

6.1. Игнорирование версий глобально

Мы можем настроить наш файл правил так, чтобыit’ll ignore versions matching a specific Regular Expression:


    
        .*-beta

6.2. Игнорирование версий для каждого правила

Наконец, в случае, если наши потребности более конкретны, мы можем вместо этого создать набор правил:

7. Заключение

Мы узнали, как проверять и обновлять зависимости проекта безопасным, автоматическим и совместимым с Maven3 способом.

Как всегда, доступен исходный кодover on GitHub вместе со сценарием, который поможет продемонстрировать все шаг за шагом и без каких-либо сложностей.

Чтобы увидеть его в действии, просто загрузите проект и запустите в терминале (или в Git Bash, если используете Windows):

./run-the-demo.sh

TOC

Используйте последнюю версию зависимости в Maven