«Плагин Maven Enforcer» - Spring на русском

«1. Обзор

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

Плагин особенно удобен, когда у нас распределенные команды, разбросанные по всему миру.

2. Зависимость

Чтобы использовать плагин в нашем проекте, нам нужно добавить следующую зависимость в наш pom.xml:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-enforcer-plugin</artifactId>
    <version>3.0.0-M2</version>
</plugin>

Последняя версия плагина доступна на Maven Central.

3. Конфигурация плагина и цели

Maven Enforcer имеет две цели: Enforcer:enforce и Enforcer:display-info.

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

Давайте определим цель принудительного выполнения в теге выполнения. Кроме того, мы добавим тег конфигурации, который содержит определения правил для проекта:

...
<executions>
    <execution>
        <id>enforce</id>
        <goals>
            <goal>enforce</goal>
        </goals>
        <configuration>
            <rules>
                <banDuplicatePomDependencyVersions/>
            </rules>
        </configuration>
    </execution>
</executions>
...

4. Правила Maven Enforcer

Ключевое слово Enforcer намекает на существование правил, которые следует соблюдать. Вот как работает плагин Maven Enforcer. Мы настраиваем его с некоторыми правилами, которые должны применяться на этапе сборки проекта.

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

4.1. Запрет дублирования зависимости

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

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

...
<rules>
    <banDuplicatePomDependencyVersions/>
</rules>
...

Чтобы проверить поведение правила, мы можем продублировать одну зависимость в pom.xml и запустить mvn clean compile. В консоли появятся следующие строки ошибок:

...
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanDuplicatePomDependencyVersions failed with message:
Found 1 duplicate dependency declaration in this project:
 - dependencies.dependency[io.vavr:vavr:jar] ( 2 times )

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.370 s
[INFO] Finished at: 2019-02-19T10:17:57+01:00
...

4.2. Требовать версии Maven и Java

Правила requireMavenVersion и requireJavaVersion позволяют блокировать требуемые версии Maven и Java на уровне проекта соответственно. Это поможет устранить несоответствие, которое может возникнуть при использовании разных версий Maven и JDK в средах разработки.

Давайте обновим секцию правил конфигурации плагина:

<requireMavenVersion>
    <version>3.0</version>
</requireMavenVersion>
<requireJavaVersion>
    <version>1.8</version>
</requireJavaVersion>

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

Кроме того, оба правила также принимают параметр сообщения для указания пользовательского сообщения:

...
<requireMavenVersion>
    <version>3.0</version>
    <message>Invalid Maven version. It should, at least, be 3.0</message>
</requireMavenVersion>
...

4.3. Требовать переменную среды

С помощью правила requireEnvironmentVariable мы можем гарантировать, что определенная переменная среды установлена в среде выполнения.

Его можно повторить для размещения более одной необходимой переменной:

<requireEnvironmentVariable>
    <variableName>ui</variableName>
</requireEnvironmentVariable>
<requireEnvironmentVariable>
    <variableName>cook</variableName>
</requireEnvironmentVariable>

4.4. Требовать активный профиль

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

Следовательно, мы можем использовать правило requireActiveProfile, когда нам нужно убедиться, что один или несколько указанных профилей активны, тем самым гарантируя успешное выполнение нашего приложения:

<requireActiveProfile>
    <profiles>local,base</profiles>
    <message>Missing active profiles</message>
</requireActiveProfile>

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

4.5. Другие правила

Плагин Maven Enforcer имеет много других правил для повышения качества и согласованности проекта независимо от среды разработки.

Кроме того, у плагина есть команда для отображения информации о некоторых настроенных правилах:

mvn enforcer:display-info

5. Пользовательские правила

До сих пор мы изучали встроенные правила плагина. Теперь пришло время взглянуть на создание собственного пользовательского правила.

Во-первых, нам нужно создать новый проект Java, который будет содержать наше пользовательское правило. Пользовательское правило — это объект класса, реализующий интерфейс EnforceRule и переопределяющий метод execute():

public void execute(EnforcerRuleHelper enforcerRuleHelper) throws EnforcerRuleException {
    try {
        String groupId = (String) enforcerRuleHelper.evaluate("${project.groupId}");
        if (groupId == null || !groupId.startsWith("org.baeldung")) {
            throw new EnforcerRuleException("Project group id does not start with org.baeldung");
        }
    }
    catch (ExpressionEvaluationException ex) {
        throw new EnforcerRuleException( "Unable to lookup an expression " 
          + ex.getLocalizedMessage(), ex );
    }
}

«Наше пользовательское правило просто проверяет, начинается ли groupId целевого проекта с org.baeldung или нет.

Обратите внимание, что нам не нужно возвращать логическое значение или что-либо подобное, чтобы указать, что правило не выполняется. Мы просто выбрасываем EnforcerRuleException с описанием того, что не так.

...
<rules>
    <myCustomRule implementation="com.baeldung.enforcer.MyCustomRule"/>
</rules>
...

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

Обратите внимание, что если проект пользовательского правила не является опубликованным артефактом в Maven Central, мы можем установить его в локальное репозиторий Maven, запустив чистую установку mvn.

Это сделает его доступным при компиляции целевого проекта с подключаемым модулем Maven Enforcer. Дополнительные сведения о пользовательском правиле см. в документации к подключаемому модулю.

Чтобы увидеть это в действии, мы можем установить для свойства groupId проекта с подключаемым модулем Enforcer любое значение, кроме «org.baeldung», и запустить mvn clean compile.

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

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

«Плагин Maven Enforcer»