Основные плагины maven

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

Каждый maven плагин имеет собственные maven координаты, такие же как у зависимостей: groupId:artifactId:version. Плагины бывают двух типов — плагины сборки и плагины отчётности. Плагины каждого типа настраиваются в собственной секции pom.xml — соответственно <build/> и <report/>. Типичная конфигурация плагина в maven выглядит следующим образом:

 

Секция executions связывает цели плагинов с фазами циклов сборки, а секция configuration позволяет задавать параметры плагинов. Maven не делает предположений о том, какие параметры могут быть у плагинов. Любая из этих секций может быть пропущена. Так, если параметры по умолчанию устраивают, можно добавить плагин к нужной фазе и всё. И наоборот, если плагин уже автоматически добавлен к какой-либо фазе, можно только указать его новые параметры.

Плагин compiler

Плагин compiler комплирует исходный java код приложения и тестов в байткод. Особенностью плагина являются его настройки по умолчанию: он ожидает, что исходный код должен быть совместим с java версии 1.5 и генерирует байткод для той же самой версии 1.5. Поэтому в каждом проекте приходится вручную выставлять версию кода:

Другая, часто используемая опция этого плагина, это задание ключей компилятора:

Плагин, как вы понимаете, сам ничего не компилирует, а вызывает javax.tools.JavaCompiler или javac, в зависимости от параметра forceJavacCompilerUse

Плагин surefire

Этот плагин реализует всю магию по исполнению юнит тестов. По умолчанию он проверяет все классы, начинающиеся словом Test* или наоборот, заканчивающиеся на *Test, *Tests, *TestCase и пытается найти в них тесты и запустить их. Плагин исполняет все найденные тесты и пишет отчёты по каждому запущенному тесту, помещая их в каталог target/surefire-reports. В случае если имеется хотя бы один провалившийся тест, плагин прерывает сборку с ошибкой.

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

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

В примере выше я говорю плагину surefire что хочу исполнять параллельно непосредственно тесты (а не, например, классы тестов или наборы тестов) и что хочу ограничиться десятью параллельными нитями исполнения.

Наконец, если тесты проваливаются, а собрать приложение всё таки очень надо, можно указать плагину, что исполнение тестов необходимо пропустить:

Этого же эффекта можно добиться, используя параметр -DskipTests в коммандной строке maven.

Плагин failsafe

Плагин failsafe — брат близнец плагина surefire и так же занимается исполнением тестов. Но failsafe, в отличие от surefire, исполняет интеграционные тесты, а не модульные. Поэтому он ищет файлы, оканчивающиеся на *IT, *ITCase или начинающиеся на IT*. Отчёты о выполнении тестов пишутся в каталог target/failsafe-reports. Кроме того, опять в отличие от surefire, плагин failsafe не проваливает сборку при ошибках тестов, тем самым позволяя выполниться цели post-integration-test, которая должна очистить окружение.

В остальном поведение плагина и его настройки идентичны предыдущему.

Плагин jar

Плагин jar отвечает за упаковку вашего приложения в jar пакет.  Наиболее часто используемая настройка этого плагина — имя выходного файла:

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

Плагин assembly

Плагин assembly был создан для того, чтобы собирать различные артефакты сборки в пакет(ы) для распространения. Например, если у вас есть веб приложение, состоящее из javascript фронтенда и java web приложения на бэкенде, с помощью плагина assembly можно собрать war пакет для сервера и zip архив с кодом клиента.

Но чаще этот плагин используют для решения проблемы с плагином jar — для сборки jar пакета с зависимостями:

Дескриптор jar-with-dependencies поставляется в комплекте с плагином и не требует дополнительной настройки. Так как плагин не встраивается в цикл сборки автоматически, приходится назначать цель сборки вручную.

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

Со следующим дескриптором:

Дескриптор выше взят из реального приложения и собирает все части single page приложения в один архив, при этом используя как сгенерированный javascript код, так и часть исходного кода. В принципе я всего лишь хотел продемонстрировать, насколько гибок assembly плагин.

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