Курс Модуль 3. Java Professional - Лекція: Просунуте складання Maven-проєкту

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>ru.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.