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
Ключевое слово « принуждение » дает тонкий намек на существование правил, которые нужно соблюдать. Вот как работает плагин 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("com.foreach")) {
throw new EnforcerRuleException("Project group id does not start with com.foreach");
}
}
catch (ExpressionEvaluationException ex) {
throw new EnforcerRuleException( "Unable to lookup an expression "
+ ex.getLocalizedMessage(), ex );
}
}
Наше пользовательское правило просто проверяет, начинается ли groupId целевого проекта с com.foreach или нет . ``
Обратите внимание, что нам не нужно возвращать логическое значение или что-либо подобное, чтобы указать, что правило не выполняется. Мы просто выбрасываем EnforcerRuleException с описанием того, что не так.
Мы можем использовать наше пользовательское правило, добавив его в качестве зависимости к плагину Maven Enforcer :
...
<rules>
<myCustomRule implementation="com.foreach.enforcer.MyCustomRule"/>
</rules>
...
Обратите внимание, что если проект настраиваемого правила не является опубликованным артефактом в Maven Central, мы можем установить его в локальное репозиторий Maven, запустив чистую установку mvn.
Это сделает его доступным при компиляции целевого проекта с подключаемым модулем Maven Enforcer. Дополнительные сведения о пользовательском правиле см. в документации к подключаемому модулю .
Чтобы увидеть его в действии, мы можем установить для свойства groupId проекта с подключаемым модулем Enforcer любое значение, кроме «com.foreach», и запустить mvn clean compile .
6. Заключение
В этом кратком руководстве мы увидели, как плагин Maven Enforcer может быть полезным дополнением к нашему набору плагинов. Возможность написания пользовательских правил расширяет диапазон его применения.
Обратите внимание, что нам нужно раскомментировать зависимости и правило для примера пользовательского правила в полном исходном коде примера, который доступен на GitHub .