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

1. Обзор

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

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

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

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

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

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

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

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

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

LATEST ищет самую новую возможную версию, в то время как RELEASE стремится к последней версии, отличной от SNAPSHOT.

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

Однако этот устаревший метод обновления приводил к непредсказуемости там, где CI требовалась воспроизводимость. Следовательно, они устарели для разрешения зависимостей плагинов.

3. Версии Плагин Maven

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

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

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

3.1. Тестовый случай

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

• три ВЫПУСКА с жестко закодированной версией
• один ВЫПУСК с версией свойства и
• один СНИМОК

<dependencies>
    <dependency>
        <groupId>commons-io</groupId>
        <artifactId>commons-io</artifactId>
        <version>2.3</version>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-collections4</artifactId>
        <version>4.0</version>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
        <version>3.0</version>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-compress</artifactId>
        <version>${commons-compress-version}</version>
    </dependency>
    <dependency>
        <groupId>commons-beanutils</groupId>
        <artifactId>commons-beanutils</artifactId>
        <version>1.9.1-SNAPSHOT</version>
    </dependency>
</dependencies>

<properties>        
    <commons-compress-version>1.15</commons-compress-version>
</properties>

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

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>2.7</version>
            <configuration>
                <excludes>
                    <exclude>org.apache.commons:commons-collections4</exclude>
                </excludes>
            </configuration>
        </plugin>
    </plugins>
</build>

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

Прежде всего, чтобы просто узнать, можем ли мы обновить наш проект и как, правильный инструмент для работы — это версии: display-dependency-updates :

mvn versions:display-dependency-updates

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

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

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

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

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

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

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

Мы можем использовать версии: use-releases , чтобы проверить, был ли опубликован соответствующий РЕЛИЗ, и даже больше, чтобы одновременно преобразовать наш СНИМОК в этот РЕЛИЗ:

mvn versions:use-releases

5.2. Обновление до следующего выпуска

Мы можем портировать каждую не-SNAPSHOT-зависимость до ее ближайшей версии с version :use-next-releases :

mvn versions:use-next-releases

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

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

5.3. Обновление до ПОСЛЕДНЕГО ВЫПУСКА

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

mvn versions:use-latest-releases

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

Если мы хотим игнорировать определенные версии, в конфигурации плагина можно настроить динамическую загрузку правил из внешнего файла:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>versions-maven-plugin</artifactId>
    <version>2.7</version>
    <configuration>
        <rulesUri>http://www.mycompany.com/maven-version-rules.xml</rulesUri>
    </configuration>
</plugin>

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

<rulesUri>file:///home/andrea/maven-version-rules.xml</rulesUri>

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

Мы можем настроить наш файл правил так, чтобы он игнорировал версии, соответствующие определенному регулярному выражению :

<ruleset comparisonMethod="maven"
  xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 
  http://mojo.codehaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
    <ignoreVersions>
        <ignoreVersion type="regex">.*-beta</ignoreVersion>
    </ignoreVersions>
</ruleset>

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

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

<ruleset comparisonMethod="maven"
  xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 
    http://mojo.codehaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
    <rules>
        <rule groupId="com.mycompany.maven" comparisonMethod="maven">
            <ignoreVersions>
                <ignoreVersion type="regex">.*-RELEASE</ignoreVersion>
                <ignoreVersion>2.1.0</ignoreVersion>
            </ignoreVersions>
        </rule>
    </rules>
</ruleset>

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

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

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

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

./run-the-demo.sh