Перейти к основному содержимому

Управление плагинами в Maven

· 5 мин. чтения

1. Обзор​

Apache Maven — это мощный инструмент, который использует подключаемые модули для автоматизации и выполнения всех задач сборки и создания отчетов в проекте Java.

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

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

2. Конфигурация плагина​

Maven имеет два типа плагинов:

  • Build — выполняется в процессе сборки. Примеры включают плагины Clean, Install и Surefire. Они должны быть настроены в разделе сборки POM.
  • Отчетность — выполняется во время создания сайта для создания различных отчетов по проекту. Примеры включают подключаемые модули Javadoc и Checkstyle. Они настраиваются в разделе отчетности POM проекта.

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

Например, мы можем объявить плагин Jar в POM: 

<build>
    ....
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <version>3.2.0</version>
            ....
        </plugin>
    ....
    </plugins>
</build>

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

3. Управление плагинами​

В дополнение к plugins мы также можем объявить плагины в разделе pluginManagement POM. Он содержит элементы плагина почти так же, как мы видели ранее. Однако при добавлении плагина в раздел pluginManagement он становится доступным для этого POM и всех наследующих дочерних POM .

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

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

4. Пример​

Начнем с создания простого многомодульного проекта с двумя подмодулями. Мы включим подключаемый модуль Build Helper в родительский POM, который содержит несколько небольших целей, помогающих в жизненном цикле сборки. В нашем примере мы будем использовать его для копирования некоторых дополнительных ресурсов в выходные данные проекта для дочернего проекта.

4.1. Конфигурация родительского POM​

Во-первых, мы добавим плагин в раздел pluginManagement родительского POM:

<pluginManagement>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>build-helper-maven-plugin</artifactId>
            <version>3.3.0</version>
            <executions>
                <execution>
                    <id>add-resource</id>
                    <phase>generate-resources</phase>
                    <goals>
                        <goal>add-resource</goal>
                    </goals>
                    <configuration>
                        <resources>
                            <resource>
                                <directory>src/resources</directory>
                                <targetPath>json</targetPath>
                            </resource>
                        </resources>
                    </configuration>
                </execution>
            </executions>
        </plugin>
   </plugins>
</pluginManagement>

Это связывает цель добавления ресурсов плагина с фазой генерации ресурсов в жизненном цикле POM по умолчанию . Мы также указали каталог src/resources , содержащий дополнительные ресурсы. Выполнение плагина скопирует эти ресурсы в целевое расположение в выходных данных проекта по мере необходимости.

Затем давайте запустим команду maven, чтобы убедиться, что конфигурация действительна и сборка прошла успешно:

$ mvn clean test

После выполнения этого целевое расположение еще не содержит ожидаемых ресурсов.

4.2. Конфигурация дочернего POM​

Теперь давайте сошлемся на этот плагин из дочернего POM:

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

Как и в случае с управлением зависимостями, мы не объявляем версию или конфигурацию плагина. Вместо этого дочерние проекты наследуют эти значения из объявления в родительском POM.

Наконец, давайте снова запустим сборку и посмотрим на результат:

....
[INFO] --- build-helper-maven-plugin:3.3.0:add-resource (add-resource) @ submodule-1 ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ submodule-1 ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.

[INFO] Copying 1 resource to json
....

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

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

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

5. Основные плагины​

Есть несколько основных плагинов Maven , которые по умолчанию используются как часть жизненного цикла сборки. Например, плагины очистки и компилятора не нужно объявлять явно.

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

Давайте попробуем это, добавив плагин компилятора в знакомый раздел pluginManagement :

<pluginManagement>
    ....
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.10.0</version>
        <configuration>
            <source>1.8</source>
            <target>1.8</target>
        </configuration>
    </plugin>
    ....
</pluginManagement>

Здесь мы заблокировали версию плагина и настроили ее для использования Java 8 для сборки проекта. Однако в дочерних проектах не требуется дополнительного объявления подключаемого модуля . Платформа сборки активирует эту конфигурацию по умолчанию. Следовательно, эта конфигурация означает, что сборка должна использовать Java 8 для компиляции этого проекта во всех модулях.

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

Это устраняет повторяющиеся объявления, упрощает файлы POM и улучшает воспроизводимость сборки.

6. Заключение​

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

Сначала мы рассмотрели плагины и их использование в проекте POM. Затем мы более подробно рассмотрели механизм управления плагинами Maven и то, как это помогает уменьшить дублирование и повысить удобство сопровождения конфигурации сборки.

Как всегда, код примера доступен на GitHub .