1. Список плагінів для збирання в Maven
Складання Maven можна налаштувати дуже гнучко. Розробники Maven спеціально створили десятки плагінів, за допомогою яких можна робити ці гнучкі налаштування. Найпопулярніші з них наведені у таблиці нижче:
Плагін | Опис | |
---|---|---|
1 | maven-compiler-plugin | Керує Java-компіляцією |
2 | maven-resources-plugin | Керує внесенням ресурсів у складання |
3 | maven-source-plugin | Керує внесенням вихідного коду у складання |
4 | maven-dependency-plugin | Керує процесом копіювання бібліотек залежностей |
5 | maven-jar-plugin | Плагін для створення підсумкового jar-файлу |
6 | maven-war-plugin | Плагін для створення підсумкового war-файлу |
7 | maven-surefire-plugin | Керує запуском тестів |
8 | buildnumber-maven-plugin | Генерує номер складання |
Кожен плагін по-своєму цікавий, і розібрати нам потрібно їх усі. Почнемо з головного – плагіна з керування компіляцією.
2. Плагін компіляції maven-compiler-plugin
Найпопулярніший плагін, що дозволяє керувати версією компілятора. Практично у всіх проєктах використовується саме maven-compiler-plugin
. У нього є стандартні налаштування, проте фактично в кожному проєкті їх потрібно встановлювати наново.
У найпростішому варіанті в плагіні потрібно зазначити версію вихідного Java-коду та версію Java-машини, під які здійснюється складання:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.2</version>
<configuration>
<source>1.11</source>
<target>1.13</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
У прикладі вище ми встановлюємо три параметри Java-компілятора: source
, target
і encoding
.
Параметр source
дозволяє вказати версію Java для наших вихідних даних. Параметр target
– версію Java-машини, під яку необхідно скомпілювати класи. Якщо версію коду або Java-машини не зазначено, за замовчуванням використовується параметр 1.3
Нарешті, параметр encoding
дозволяє зазначити кодування Java-файлів. Ми вказали UTF-8
. Наразі практично всі вихідні коди зберігаються в кодуванні UTF-8
. Але якщо цей параметр не вказано, обереться поточне кодування операційної системи. Для Windows це кодування Windows-1251
.
Також стаються випадки, коли комп'ютер, на якому проводиться складання, має кілька встановлених версій Java: для складання різних модулів та/або різних проєктів. І тут у змінної JAVA_HOME
може бути лише шлях до однієї з них.
До того ж, бувають різні реалізації Java-машини: OpenJDK, OracleJDK, Amazon JDK. Чим більший проект, тим складніша його структура. Але ви можете явно зазначити для плагіна шлях до компілятора javac за допомогою тега
Плагін maven-compiler-plugin
має дві цілі (goals):
compiler:compile
– компіляція вихідних джерел, за замовчуванням пов'язана з фазою compile;compiler:testCompile
– компіляція тестів, за замовчуванням пов'язана з фазою test-compile.
Також можна вказати список аргументів, які передаватимуться javac-компілятору в командному рядку:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.2</version>
<configuration>
<compilerArgs>
<arg>-verbose</arg>
<arg>-Xlint:all,-options,-path<arg>
</compilerArgs>
</configuration>
</plugin>
3. Плагін створення jar-файлу maven-jar-plugin
Якщо ти захочеш зібрати власну jar-бібліотеку за допомогою Maven, тобі знадобиться плагін maven-jar-plugin. Цей плагін вміє робити багато корисного.
Приклад такого плагіна:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<includes>
<include>**/properties/*</include>
</includes>
<archive>
<manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
По-перше, за його допомогою можна вказати, які файли потраплятимуть до бібліотеки, а які – ні. За допомогою тегів <include>
у секції <includes>
можна вказати список директорій, чий контент потрібно додати до бібліотеки.
По-друге, кожна jar-бібліотека повинна мати маніфест (файл MANIFEST.MF). Плагін сам покладе його в потрібне місце бібліотеки – тобі лише потрібно вказати, яким способом його взяти. Для цього використовується тег <manifestFile>
.
І, нарешті, плагін може самостійно згенерувати маніфест. Для цього замість тега <manifestFile>
тобі потрібно додати тег <manifest>
і вказати дані для майбутнього маніфесту. Приклад:
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
<mainClass>com.javarush.MainApplication</mainClass>
</manifest>
</archive>
</configuration>
Тег <addClasspath>
визначає необхідність додавання до маніфесту CLASSPATH
.
Тег <classpathPrefix>
дозволяє дописувати префікс (у прикладі lib) перед кожним ресурсом. Визначення префікса <classpathPrefix>
дозволяє розміщувати залежності в окремій папці.
Так, ти можеш розміщувати бібліотеки всередині іншої бібліотеки. І на тебе чекає багато сюрпризів, коли буде потрібно кудись передати шлях до properties-файлу, який знаходиться в jar-бібліотеці, що знаходиться в іншій jar-бібліотеці.
І нарешті, тег <mainClass>
вказує на головний клас, що виконується. Що це за головний клас, що виконується? Справа в тому, що Java-машина може запустити програму, яка зазначена не лише Java-класом, а й jar-файлом. І саме для такого випадку потрібен головний стартовий клас.
4. Плагін генерації номера складання buildnumber-maven-plugin
Дуже часто jar-бібліотеки та war-файли містять інформацію з назвою проєкту та його версією, а також версією складання. Мало того, що це корисно для керування залежностями, так ще й спрощує тестування: зрозуміло, в якій версії бібліотеки помилку виправлено, а в якій – додано.
Найчастіше це завдання вирішують так: створюють спеціальний файл application.properties
, який містить всю потрібну інформацію, і додають його до складання проєкту. Також можна налаштувати сценарій складання таким чином, щоб дані з цього файлу перекочовували до MANIFEST.MF
тощо.
Але найцікавіше те, що Maven має спеціальний плагін, який може генерувати такий application.properties файл. Для цього потрібно створити такий файл і заповнити його спеціальними шаблонами даних. Приклад:
# application.properties
app.name=${pom.name}
app.version=${pom.version}
app.build=${buildNumber}
Значення всіх трьох параметрів будуть підставлятися на етапі збирання.
Параметри pom.name
і pom.version
беруться прямо з pom.xml
. А для створення унікального номера складання в Maven є спеціальний плагін – buildnumber-maven-plugin
. Поглянь на приклад нижче:
<packaging>war</packaging>
<version>1.0</version>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
<configuration>
<revisionOnScmFailure>true</revisionOnScmFailure>
<format>{0}-{1,date,yyyyMMdd}</format>
<items>
<item>${project.version}</item>
<item>timestamp</item>
</items>
</configuration>
</plugin>
</plugins>
У цьому прикладі відбуваються три важливі речі. По-перше, вказано сам плагін для встановлення версії складання. По-друге, зазначено, що він запускатиметься під час фази validate (найперша фаза) і генеруватиме номер складання – ${buildNumber}
.
І по-третє, вказано формат цього номера складання, який формується з кількох частин. Це версія проєкту project.version
та поточний час, зазначений шаблоном. Формат шаблону встановлюється Java-класом MessageFormat
.