В статье о сборочных циклах я писал, что maven предоставляет инфраструктуру и устанавливает правила, а всю настоящую работу делают плагины. Какие же это плагины и какие у них настройки?
Каждый maven плагин имеет собственные maven координаты, такие же как у зависимостей: groupId:artifactId:version. Плагины бывают двух типов — плагины сборки и плагины отчётности. Плагины каждого типа настраиваются в собственной секции pom.xml — соответственно <build/> и <report/>. Типичная конфигурация плагина в maven выглядит следующим образом:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
<build>
<plugins>
<plugin>
<groupId>group</groupId>
<artifactId>artifact</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<goals>
<goal>somePluginGoal</goals>
<goals>
<phase>integration-test</phase
</execution>
</executions>
<configiuration>
<some>values</some>
</configuration>
</plugin>
</plugins>
</build>
|
Секция executions связывает цели плагинов с фазами циклов сборки, а секция configuration позволяет задавать параметры плагинов. Maven не делает предположений о том, какие параметры могут быть у плагинов. Любая из этих секций может быть пропущена. Так, если параметры по умолчанию устраивают, можно добавить плагин к нужной фазе и всё. И наоборот, если плагин уже автоматически добавлен к какой-либо фазе, можно только указать его новые параметры.
Плагин compiler
Плагин compiler комплирует исходный java код приложения и тестов в байткод. Особенностью плагина являются его настройки по умолчанию: он ожидает, что исходный код должен быть совместим с java версии 1.5 и генерирует байткод для той же самой версии 1.5. Поэтому в каждом проекте приходится вручную выставлять версию кода:
|
1
2
3
4
5
6
7
8
9
|
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.6.2</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
|
Другая, часто используемая опция этого плагина, это задание ключей компилятора:
|
1
2
3
4
5
6
7
8
9
10
11
|
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.6.2</version>
<configuration>
<compilerArgs>
<arg>-verbose</arg>
<arg>-Xlint:all,-options,-path</arg>
</compilerArgs>
</configuration>
</plugin>
|
Плагин, как вы понимаете, сам ничего не компилирует, а вызывает javax.tools.JavaCompiler или javac, в зависимости от параметра forceJavacCompilerUse
Плагин surefire
Этот плагин реализует всю магию по исполнению юнит тестов. По умолчанию он проверяет все классы, начинающиеся словом Test* или наоборот, заканчивающиеся на *Test, *Tests, *TestCase и пытается найти в них тесты и запустить их. Плагин исполняет все найденные тесты и пишет отчёты по каждому запущенному тесту, помещая их в каталог target/surefire-reports. В случае если имеется хотя бы один провалившийся тест, плагин прерывает сборку с ошибкой.
Список классов к запуску может быть изменён и в него могут быть включены дополнительные файлы или наоборот, исключены ненужные:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.20</version>
<configuration>
<includes>
<include>Sample.java</include>
</includes>
<excludes>
<exclude>**/TestCircle.java</exclude>
<exclude>**/TestSquare.java</exclude>
</excludes>
</configuration>
</plugin>
|
Интересной возможностью плагина является возможность исполнения тестов параллельно. Так как юнит-тесты должны быть независимы друг от друга, это, обычно, вполне безопасно и позволяет сократить время исполнения тестов. По умолчанию параллельное исполнение не включено и требует дополнительной настройки:
|
1
2
3
4
5
6
7
8
9
|
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.20</version>
<configuration>
<parallel>methods</parallel>
<threadCount>10</threadCount>
</configuration>
</plugin>
|
В примере выше я говорю плагину surefire что хочу исполнять параллельно непосредственно тесты (а не, например, классы тестов или наборы тестов) и что хочу ограничиться десятью параллельными нитями исполнения.
Наконец, если тесты проваливаются, а собрать приложение всё таки очень надо, можно указать плагину, что исполнение тестов необходимо пропустить:
|
1
2
3
4
5
6
7
8
|
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.20</version>
<configuration>
<skipTests>true</skipTests>
</configuration>
</plugin>
|
Этого же эффекта можно добиться, используя параметр -DskipTests в коммандной строке maven.
Плагин failsafe
Плагин failsafe — брат близнец плагина surefire и так же занимается исполнением тестов. Но failsafe, в отличие от surefire, исполняет интеграционные тесты, а не модульные. Поэтому он ищет файлы, оканчивающиеся на *IT, *ITCase или начинающиеся на IT*. Отчёты о выполнении тестов пишутся в каталог target/failsafe-reports. Кроме того, опять в отличие от surefire, плагин failsafe не проваливает сборку при ошибках тестов, тем самым позволяя выполниться цели post-integration-test, которая должна очистить окружение.
В остальном поведение плагина и его настройки идентичны предыдущему.
Плагин jar
Плагин jar отвечает за упаковку вашего приложения в jar пакет. Наиболее часто используемая настройка этого плагина — имя выходного файла:
|
1
2
3
4
5
6
7
8
|
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<finalName>myJar</finalName>
</configuration>
</plugin>
|
Особенностью плагина jar является минималистичность сборки, в которую попадают только классы вашего приложения, без их зависимостей.
Плагин assembly
Плагин assembly был создан для того, чтобы собирать различные артефакты сборки в пакет(ы) для распространения. Например, если у вас есть веб приложение, состоящее из javascript фронтенда и java web приложения на бэкенде, с помощью плагина assembly можно собрать war пакет для сервера и zip архив с кодом клиента.
Но чаще этот плагин используют для решения проблемы с плагином jar — для сборки jar пакета с зависимостями:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</plugin>
|
Дескриптор jar-with-dependencies поставляется в комплекте с плагином и не требует дополнительной настройки. Так как плагин не встраивается в цикл сборки автоматически, приходится назначать цель сборки вручную.
Сам плагин настраивается дескриптором сборки, который может быть как встроен в плагин, так и написан вручную. Скажем для примера выше, с приложением состоящим из фронтенда и бэкенда, можно было бы использовать следующую конфигурацию плагина:
|
1
2
3
4
5
6
7
8
9
|
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.5.5</version>
<configuration>
<descriptors>
<descriptor>src/main/assembly/static.xml</descriptor>
</descriptors>
</configuration>
</plugin>
|
Со следующим дескриптором:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
<assembly>
<id>static</id>
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<fileSet>
<directory>src/main/webapp</directory>
<outputDirectory>/</outputDirectory>
<includes>
<include>/css/**</include>
<include>/images/**</include>
<include>/js/ext/locale/**</include>
<include>/js/ext/ext.js</include>
<include>/js/App/locale/**</include>
</includes>
</fileSet>
<fileSet>
<directory>${project.build.directory}/sencha</directory>
<outputDirectory>/</outputDirectory>
<includes>
<include>/index.html</include>
<include>/all-classes.js</include>
</includes>
</fileSet>
</fileSets>
</assembly>
|
Дескриптор выше взят из реального приложения и собирает все части single page приложения в один архив, при этом используя как сгенерированный javascript код, так и часть исходного кода. В принципе я всего лишь хотел продемонстрировать, насколько гибок assembly плагин.
Вышеприведённый список плагинов конечно же не полный и не покрывает и трети только официальных плагинов, не говоря уже о плагинах сторонних разработчиков. Кроме того, вы можете разрабатывать свои плагины и как это сделать я опишу в следующей статье.