Фреймворк Apache Maven

Apache Maven предназначен для автоматизации процесса сборки проектов на основе описания их структуры в файле на языке POM (Project Object Model), который является подмножеством формата XML. maven позволяет выполнять компиляцию кодов, создавать дистрибутив программы, архивные файлы jar/war и генерировать документацию. Простые проекты maven может собрать в командной строке. Название программы maven вышло из языка идиш, смысл которого можно выразить как «собиратель знания».

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

Если описать maven на одной странице сайта, да еще привести примеры использования, то содержимое будет «нечитабельным» - это слишком большой объём информации для представления далеко не всех его возможностей. Поэтому описание разнесено по нескольким страницам. На этой странице представлено общее описание maven. На странице Примеры проектов maven описано использование maven для разнотипных проектов. Отдельными страницами представлено «применение maven в IDE Eclipse» (в разработке) и «плагины maven» (в разработке).

Инсталляция maven

Последнюю версию maven можно скачать в виде zip-архива со страницы загрузки на официальном сайте. После этого необходимо выполнить несколько шагов :

  • распаковать архив в инсталляционную директорию. Например в директорию C:\maven-x.y.z в Windows или /opt/maven-x.y.z в Linux
  • установить переменную окружения M2_HOME :
    • в Windows кликните правой кнопкой мыши на «Мой компьютер» и откройте окно Свойства/«Дополнительные параметры»/«Переменные среды»/«Системные переменные», в котором добавьте «M2_HOME» = "C:\maven-x.y.z\";
    • в Linux можно добавить строку «export M2_HOME=/opt/maven-x.y.z» в файл /etc/profile;
  • Внесите изменения в переменную окружения PATH :
    • в Windows в переменную PATH добавьте строку %M2_HOME%\bin;
    • в Linux можно добавить строку «export PATH=$PATH:$M2_HOME/bin» в файл /etc/profile;

Чтобы убедиться, что maven установлен, необходимо в командной строке ввести следующую команду :


mvn -–version
 

Должна появиться информация о версиях maven, jre и операционной системе типа :


Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T19:41:47+03:00)
Maven home: C:\apache-maven-3.3.9
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\jre
Default locale: ru_RU, platform encoding: Cp1251
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
 

При инсталляции maven'a будет создан локальный репозиторий в вашей личной папке ${user.home}\.m2\repository. После этого можно считать, что maven готов к работе и можно приступать к созданию проектов сборки приложений.

Одной из привлекательных особенностей maven'a является справка online, работоспособность которой можно проверить после инсталляции. К примеру справку по фазе компиляции можно получить следующей командой :

mvn help:describe -Dcmd=compile

В результате Вы увидите следующую справочную информацию :

[INFO] 'compile' is a phase corresponding to this plugin:
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile

It is a part of the lifecycle for the POM packaging 'jar'. 
This lifecycle includes the following phases:
* validate: Not defined
* initialize: Not defined
* generate-sources: Not defined
* process-sources: Not defined
* generate-resources: Not defined
* process-resources: \
        org.apache.maven.plugins:maven-resources-plugin:2.6:resources
* compile: org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
* process-classes: Not defined
* generate-test-sources: Not defined
* process-test-sources: Not defined
* generate-test-resources: Not defined
* process-test-resources: \
        org.apache.maven.plugins:maven-resources-plugin:2.6:testResources
* test-compile: \
        org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile
* process-test-classes: Not defined
* test: org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test
* prepare-package: Not defined
* package: org.apache.maven.plugins:maven-jar-plugin:2.4:jar
* pre-integration-test: Not defined
* integration-test: Not defined
* post-integration-test: Not defined
* verify: Not defined
* install: org.apache.maven.plugins:maven-install-plugin:2.4:install
* deploy: org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.742 s
[INFO] Finished at: 2016-09-19T22:41:26+04:00
[INFO] Final Memory: 7M/18M
[INFO] ------------------------------------------------------------------------

Репозитории проекта, repositories

Под репозиторием (repository) понимается, как правило, внешний центральный репозиторий, в котором собрано огромное количество наиболее популярных и востребованных библиотек, и локальный репозиторий, в котором хранятся копии используемых ранее библиотек.

Дополнительные репозитории, необходимые для сборки проекта, перечисляются в секции <repositories> проектного файла pom.xml :

<project>
    ...
    <repositories>
        <repository>
            <id>repo1.maven.org</id>
            <url>http://repo1.maven.org/maven2</url>
        </repository>
    </repositories>
    ...
</project>

Можно создать и подключать к проектам свой репозиторий, содержимое которого можно полностью контролировать и сделать его доступным для ограниченного количества пользователей. Доступ к содержимому репозитория можно ограничивать настройками безопасности сервера так, что код ваших проектов не будет доступен из вне. Существуют несколько реализаций серверов - репозиториев maven; к наиболее известным относятся artifactory, continuum, nexus.

Таким образом, репозиторий - это место, где хранятся файлы jar, pom, javadoc, исходники и т.д. В проекте могут быть использованы :

  • центральный репозиторий, доступный на чтение для всех пользователей в интернете;
  • внутренний «корпоративный» репозиторий - дополнительный репозиторий группы разработчиков;
  • локальный репозиторий, по умолчанию расположен в ${user.home}/.m2/repository - персональный для каждого пользователя.

Для добавления, к примеру, библиотеки carousel-lib.jar в локальный репозиторий можно использовать команду mvn install (команда должна быть однострочной) :

mvn install:install-file
    -Dfile=${FILE_PATH}/carousel-lib.jar
    -DgroupId=ru.carousel
    -DartifactId=carousel-lib
    -Dversion=1.0
    -Dpackaging=jar
    -DgeneratePom=true

В локальном репозитории «.m2» maven создаст директорию ru/carousel, в которой разместит данную библиотеку и создаст к ней описание в виде pom.xml.

Репозиторий можно также разместить внутри проекта. Описания процесса создания и размещения репозитория внутри проекта с примером можно прочитать здесь.

Терминология maven

В maven используется свой набор терминов и понятий. Ключевым понятием maven является артефакт (artifact) — это, по сути, любая библиотека, хранящаяся в репозитории, к которой можно отнести зависимость или плагин.

Зависимости (dependencies) представляют собой библиотеки, которые непосредственно используются в проекте для компиляции или тестирования кода.

При сборке проекта или для каких-то других целей (deploy, создание файлов проекта для Eclipse и др.) maven использует плагины (plugin).

Еще одним важным понятием maven проекта является архетип (archetype) - это некая стандартная компоновка каталогов и файлов в проектах различного типа (web, maven, swt/swing-проекты и прочие). Иными словами maven знает, как построить структуру проекта в соответствии с его архетипом.

Архетипы maven

Количество архетипов у maven'a огромно, «на разный вкус». Как правильно выбрать нужный, чтобы создать архитектуру будущего проекта? Просматривать в консоли не очень удобно, тем более что их количество переваливает за 1500 (к примеру для версии maven 3.3.9 на моем компьютере их 1665). Поэтому можно скачать их в отдельный файл, а потом со всем этим хозяйством разбираться. Для этого необходимо выполнить следующую команду :


mvn archetype:generate > archetypes.txt
 

В результате в файле archetypes.txt можно увидеть, что-то подобное

[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] -------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] -------------------------------------------------------------------
[INFO] 
[INFO] >>> maven-archetype-plugin:2.4:generate (default-cli) > 
                    generate-sources @ standalone-pom >>>
[INFO] 
[INFO] <<< maven-archetype-plugin:2.4:generate (default-cli) < 
                    generate-sources @ standalone-pom <<<
[INFO] 
[INFO] maven-archetype-plugin:2.4:generate (default-cli) @ standalone-pom
[INFO] Generating project in Interactive mode
[INFO] No archetype defined. Using maven-archetype-quickstart \
       (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
Choose archetype:
1: remote -> am.ik.archetype:maven-reactjs-blank-archetype
                                 (Blank Project for React.js)
2: remote -> am.ik.archetype:msgpack-rpc-jersey-blank-archetype 
                                 (Blank Project for Spring Boot + Jersey)
3: remote -> am.ik.archetype:mvc-1.0-blank-archetype
                                 (MVC 1.0 Blank Project)
4: remote -> am.ik.archetype:spring-boot-blank-archetype
                                 (Blank Project for Spring Boot)
5: remote -> am.ik.archetype:spring-boot-docker-blank-archetype
                                 (Docker Blank Project for Spring Boot)
 
...

При выполнении данной команды maven, после скачивания информации в файл, ожидает поступления команды пользователя. Т.е., находится в ожидании интерактивного ввода команд по созданию проекта определенного типа. Если файл уже создан, то прервите выполнение команды двойным нажатием клавишам Ctrl+C.

Для создания простенького maven проекта «carousel» (карусель) необходимо выполнить следующую команду :

mvn archetype:generate
    -DgroupId=ru.carousel
    -DartifactId=carousel
    -Dversion=1.0-SNAPSHOT
    -DarchetypeArtifactId=maven-archetype-quickstart

На странице Примеры maven проектов подробно описываются разнотипные maven проекты - проект консольного приложения без зависимостей, приложение с графическим интерфейсом и с зависимостями, web-приложение с фреймворком.

Архитектура простого maven проекта

Следующая структура показывает директории простого maven проекта.

Проектный файл pom.xml располагается в корне каталога.

  • src: исходные файлы;
  • src/main: исходные коды проекта;
  • src/main/java: исходные java-файлы;
  • src/main/resources: ресурсные файлы, которые используются при компиляции или исполнении, например properties-файлы;
  • src/test: исходные файлы для организации тестирования;
  • src/test/java: JUnit-тест-задания для автоматического тестирования;
  • target: создаваемые в процессе работы maven'a файлы для сборки проекта.

В зависимости от типа приложения (консольное, с интерфейсом, web, gwt и т.д.) структура может отличаться. В директории target maven собирает проект (jar/war).

На официальном сайте Apache Maven Project можно получить дополнительную информацию об архетипах (Introduction to Archetypes).

Жизненный цикл maven проекта

Жизненный цикл maven проекта – это чётко определённая последовательность фаз. Когда maven начинает сборку проекта, он проходит через определённую последовательность фаз, выполняя задачи, указанные в каждой из фаз. Maven имеет 3 стандартных жизненных цикла :

  • clean — жизненный цикл для очистки проекта;
  • default — основной жизненный цикл;
  • site — жизненный цикл генерации проектной документации.

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

Фазы жизненного цикла clean

  • pre-clean;
  • clean;
  • post-clean.

Фазы жизненного цикла default

  • validate - выполнение проверки, является ли структура проекта полной и правильной;
  • generate-sources - включение исходного кода в фазу;
  • process-sources - подготовка/обработка исходного кода; например, фильтрация определенных значений;
  • generate-resources - генерирование ресурсов, которые должны быть включены в пакет;
  • process-resources - копирование ресурсов в указанную директорию (перед упаковкой);
  • compile - компиляция исходных кодов проекта;
  • process-test-sources - обработка исходных кодов тестов;
  • process-test-resources - обработка ресурсов для тестов;
  • test-compile - компиляция исходных кодов тестов;
  • test - собранный код тестируется, используя приемлемый фреймворк типа JUnit;
  • package - упаковка откомпилированных классов и прочих ресурсов в дистрибутивный формат;
  • integration-test - программное обеспечение в целом или его крупные модули подвергаются интеграционному тестированию. Проверяется взаимодействие между составными частями программного продукта;
  • install - установка программного обеспечения в maven-репозиторий, чтобы сделать его доступным для других проектов;
  • deploy - стабильная версия программного обеспечения копируется в удаленный maven-репозиторий, чтобы сделать его доступным для других пользователей и проектов;

Фазы жизненного цикла site

  • pre-site;
  • site;
  • post-site;
  • site-deploy;

Стандартные жизненные циклы могут быть дополнены функционалом с помощью maven-плагинов. Плагины позволяют вставлять в стандартный цикл новые шаги (например, распределение на сервер приложений) или расширять существующие шаги.

Порядок выполнения команд maven проекта зависит от порядка вызова целей и фаз. Следующая команда


mvn clean dependency:copy-dependencies package
 

выполнит фазу clean, после этого будет выполнена задача dependency:copy-dependencies, после чего будет выполнена фаза package. Аргументы clean и package являются фазами сборки, dependency:copy-dependencies является задачей.

Зависимости, dependencies

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

  • compile - область, используемая по умолчанию, говорит, что бинарные сборки зависисимости требуются на этапе компиляции, выполнения тестов и во время выполнения;
  • provided - область аналогична compile, за исключением того, что JDK или контейнер сам предоставит зависимость во время выполнения программы.
  • runtime - зависимость не нужна для компиляции, но нужна для выполнения.
  • test - зависимость не нужна для нормальной работы приложения, а нужна только для компиляции и запуска тестов.
  • system - область аналогична provided за исключением того, что содержащий зависимость JAR указывается явно. Артефакт не ищется в репозитории.
  • import (начиная с версии Maven 2.0.9) используется только с зависимостью типа pom в секции <dependencyManagement>. Зависимости текущего POM заменяются на зависимости из указанного POM.

Зависимости проекта описываются в секции <dependencies> файла pom.xml. Для каждой используемой в проекте библиотеки необходимо указать GAV (groupId, artifactId, version), где идентификатор группы (groupId), идентификатор артефакта (artifactId), а также требуемую ее версию (version). Как правило информации GAV достаточно maven'у, для поиска указанной библиотеки в репозиториях.

Часто, в качестве зависимости проекта, используют собственные наработки. Конечно же, искать их в центральном репозитории не имеет смысла. В данной ситуации есть два пути: можно описать зависимость как системную и указать физический путь к библиотеке, или добавить библиотеку в локальный репозиторий maven'а, что является более предпочтительным, если Вы работаете индивидуально.

Чтобы описать зависимость как системную, необходимо наряду с GAV указать ешё scope, для которого устанавливается значение system. Пример описания системной зависимости :

<dependencies>
    <dependency>
        <groupId>ru.carousel</groupId>
        <artifactId>carousel-lib</artifactId>
        <version>1.0</version>
        <scope>system</scope>
        <systemPath>
               ${home.dir}/projects/libs/carousel-lib.jar
        </systemPath>
    </dependency>
</dependencies>

groupId - идентификатор производителя объекта. Часто используется схема принятая в обозначении пакетов Java. Например, если производитель имеет домен domain.com, то в качестве значения groupId удобно использовать значение com.domain. То есть, groupId это по сути имя пакета.

artifactId - идентификатор объекта. Обычно это имя создаваемого модуля или приложения.

version — версия описываемого объекта. Для незавершенных проектов принято добавлять суффикс SNAPSHOT. Например 1.0-SNAPSHOT.

Значения идентификаторов groupId и artifactId подключаемых библиотек практически всегда можно найти на сайте www.mvnrepository.com. Если найти требуемую библиотеку в этом репозитории не удается, то можно использовать дополнительный репозиторий http://repo1.maven.org/maven2.

Плагины, plugins

Maven базируется на plugin-архитектуре, которая позволяет использовать плагины для различных задач (test, compile, build, deploy и т.п). Иными словами, maven запускает определенные плагины, которые выполняют всю работу. То есть, если мы хотим научить maven особенным сборкам проекта, то необходимо добавить в pom.xml указание на запуск нужного плагина в нужную фазу и с нужными параметрами. Это возможно за счет того, что информация поступает плагину через стандартный вход, а результаты пишутся в его стандартный выход.

Количество доступных плагинов очень велико и включает разнотипные плагины, позволяющие непосредственно из maven запускать web-приложение для тестирования его в браузере, генерировать Web Services. Главной задачей разработчика в этой ситуации является найти и применить наиболее подходящий набор плагинов.

В простейшем случае запустить плагин просто - для этого необходимо выполнить команду в определенном формате. Например, чтобы запустить плагин «maven-checkstyle-plugin» (artifactId) с groupId равным «org.apache.maven.plugins» необходимо выполнить следующую команду :

 
mvn org.apache.maven.plugins:maven-checkstyle-plugin:check
 

Целью (goal) выполнения данного плагина является проверка "check". Можно запустить в более краткой форме :

 
mvn maven-checkstyle-plugin:check
 

Объявление плагина в проекте похоже на объявление зависимости. Плагины также идентифицируется с помощью GAV (groupId, artifactId, version). Например:

<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-checkstyle-plugin</artifactId>
        <version>2.6</version>
    </plugin>
</plugins>

Объявление плагина в pom.xml позволяет зафиксировать версию плагина, задать ему необходимые параметры, определить конфигурационные параметры, привязать к фазам.

Что касается списка конфигурационных переменных плагина, то его легко можно найти на сайте maven. К примеру, для maven-compiler-plugin, на странице Apache Maven Project можно увидеть перечень всех переменных, управляющих плагином.

Разные плагины вызываются maven'ом на разных стадиях жизненного цикла. Так проект, формирующий настольное java-приложение с использованием библиотек swing или swt, имеет стадии жизненного цикла отличные от тех, что характерны для разработке enterprise application (ear). Еак например, когда выполняется команда «mvn test», инициируeтся целый набор шагов в жизненном цикле проекта: «process-resources”, «compile», «process-classes», «process-test-resources», «test-compile», «test». Упоминания этих фаз отражаются в выводимых maven-ом сообщениях :

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building carousel 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) \
           @ carousel ---
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) \
           @ carousel
[INFO] --- maven-resources-plugin:2.6:testResources \
           (default-testResources) @ carousel ---
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) \
           @ carousel ---
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) \
           @ carousel ---
[INFO] Surefire report directory: \
           E:\maven.projects\carousel\target\surefire-reports

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running ru.carousel.AppTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec

Results :

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.042 s
[INFO] Finished at: 2016-09-24T12:33:45+04:00
[INFO] Final Memory: 7M/18M
[INFO] ------------------------------------------------------------------------

В каждой фазе жизненного цикла проекта вызывается определенный плагин (jar-библиотека), который включает некоторое количество целей (goal). Например, плагин «maven-compiler-plugin» содержит две цели: «compiler:compile» для компиляции основного исходного кода проекта и «compiler:testCompile» для компиляции тестов. Формально, список фаз можно изменять, хотя такая ситуация случается крайне редко.

В проектном файле pom.xml можно настроить для каждого из плагинов жизненного цикла набор конфигурационных переменных, например :

<build>
  <plugins>
    <plugin>
      <artifactId>maven-compiler-plugin</artifactId>
      <configuration>
        <verbose>true</verbose>
        <executable>
              C:/Program_Files/Java/jdk1.7.0_67/bin/javac.exe
        </executable>
        <source>1.7</source>
        <target>1.7</target>
      </configuration>
    </plugin>
  </plugins>
</build>

В случае необходимости выполнения нестандартных действий в определенной фазе, например, на стадии генерации исходников «generate-sources», можно добавить вызов соответствующего плагина в файле pom.xml :

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>имя-плагина</artifactId>
  <executions>
    <execution>
      <id>customTask</id>
      <phase>generate-sources</phase>
      <goals>
         <goal>pluginGoal</goal>
      </goals>
...

Самое важное в данном случае – это определить для плагина наименование фазы «execution/phase», в которую нужно встроить вызов цели плагина «goal». Фаза «generate-sources» располагается перед вызовом фазы compile и очень удобна для генерирования части исходных кодов проекта.

Описание различных плагинов представлено на странице Maven плагины для сборки проекта.

Основные исполняемые цели, goal

Использование maven часто сводится к выполнению одной из команды следующего набора, которые можно назвать целями (по аналогии с другими системами сборки типа ant, make) :

  • validate — проверка корректности метаинформации о проекте;
  • compile — компилиляция исходников;
  • test — прогонка тестов классов;
  • package — упаковка скомпилированнных классов в заданный формат (jar или war, к примеру);
  • integration-test — отправка упакованных классов в среду интеграционного тестирования и прогонка тестов;
  • verify — проверка корректности пакета и удовлетворение требованиям качества;
  • install — отправка пакета в локальный репозиторий, где он будет доступен для использования как зависимость в других проектах;
  • deploy — отправка пакета на удаленный production сервер, где доступ к нему будет открыт другим разработчикам.

В общем случае для выполнения команды maven необходимо выполнить следующий код : «mvn цель». В качестве параметров указываются не только имена фаз, но и имена и цели плагинов в формате «mvn плагин:цель». Например, вызов фазы цикла «mvn clean» эквивалентен вызову плагина «mvn clean:clean».

Секция свойств maven проекта, properties

Отдельные настройки проекта можно определить в переменных. Это может быть связанно, к примеру, с тем, что требуется использовать семейство библиотек определенной версии. Для этого в проектном файле используется секция <properties>, в которой объявляются переменные. Обращение к переменной выглядит следующим образом : ${имя переменной}. Пример описания свойств проекта и их использование :

<properties>
    <junit.version>4.11</junit.version>
    <maven.compiler.source>1.4</maven.compiler.source>
    <maven.compiler.target>1.6</maven.compiler.target>
</properties>

…
<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>${junit.version}</version>
        <scope>test</scope>
    </dependency>
</dependencies>
…
<build>
    <finalName>${project.artifactId}</finalName>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.3.2</version>
        <configuration>
            <source>${maven.compiler.source}</source>
            <target>${maven.compiler.target}</target>
        </configuration>
    </plugin>
</build>
…

Кодировка maven проекта

При выполнении отдельных команд maven, связанных с копированием ресурсов или компиляцией, могут «выплыть» предупреждения о кодировке :

[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ ...
[WARNING] Using platform encoding (Cp1251 actually) to copy filtered
                             resources, i.e. build is platform dependent!

[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ ...
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding Cp1251,
                                        i.e. build is platform dependent!

Чтобы обойти эти сообщения, необходимо включить в секцию <properties> следующий код с указанием требуемой кодировки :

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

Для просмотра свойств проекта можно использовать плагин «maven-echo-plugin» :

<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>groovy-maven-plugin</artifactId>
    <version>2.0</version>
    <executions>
        <execution>
            <phase>validate</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <source>
                    log.info('JUnit версия : {0}', junit.version)
                </source>
            </configuration>
        </execution>
    </executions>
</plugin>

Проектный файл, pom.xml

Структура проекта описывается в файле pom.xml, который должен находиться в корневой папке проекта. Содержимое проектного файла имеет следующий вид :

<project xmlns="http://maven.apache.org/POM/4.0.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
     http://maven.apache.org/xsd/maven-4.0.0.xsd">
   
    <modelVersion>4.0.0</modelVersion>

    <!-- GAV параметры описания проекта -->
    <groupId>...</groupId>
    <artifactId>...</artifactId>
    <packaging>...</packaging>
    <version>...</version>

    <!-- Секция свойств -->
    <properties>
        . . .
    </properties>

    <!-- Секция репозиториев -->
    <repositories>
        . . .
    </repositories>

    <!-- Секция зависимостей -->
    <dependencies>
        . . .
    </dependencies>
  
    <!-- Секция сборки -->
    <build>
        <finalName>projectName</finalName>
        <sourceDirectory>${basedir}/src/java</sourceDirectory>
        <outputDirectory>${basedir}/targetDir</outputDirectory>
        <resources>
            <resource>
                <directory>${basedir}/src/java/resources</directory>
                <includes>
                    <include>**/*.properties</include>
                </includes>
            </resource>
        </resources>
        <plugins>
            . . .
        </plugins>
    </build>
</project>

Не все секции могут присутствовать в описании pom.xml. Так секции properties и repositories часто не используются. Параметры GAV проекта являются обязательными. Выше на странице было представлено описание использования различных секций. Здесь рассмотрим только секцию <build>.

Секция build

Секция <build> также не является обязательной, т. к. существует значение по умолчанию. Данная секция содержит информацию по самой сборке, т.е. где находятся исходные файлы, файлы ресурсов, какие плагины используются.

  • <finalName> - наименование результирующего файла сборки (jar, war, ear..), который создаётся в фазе package. Значение по умолчанию — «artifactId-version»;
  • <sourceDirectory> - определение месторасположения файлов с исходным кодом. По умолчанию файлы располагаются в директории «${basedir}/src/main/java», но можно определить и в другом месте;
  • <outputDirectory> - определение месторасположения директории, куда компилятор будет сохранять результаты компиляции - *.class файлы. По умолчанию определено значение «target/classes»;
  • <resources> и вложенные в неё тэги <resource> определяют местоположение файлов ресурсов. Ресурсы, в отличие от файлов исходного кода, при сборке просто копируются в директорию, значение по умолчанию которой равно «src/main/resources».

Предопределёные переменные maven

При описании проекта в pom-файле можно использовать предопределенные переменные. Их можно условно разделить на несколько групп :

  • Встроенные свойства проекта :
    • ${basedir} - корневой каталог проекта, где располагается pom.xml;
    • ${version} - версия артифакта; можно использовать ${project.version} или ${pom.version};
  • Свойства проекта. На свойства можно ссылаться с помощью префиксов «project» или «pom» :
    • ${project.build.directory} - «target» директория (можно ${pom.build.directory});
    • ${project.build.outputDirectory} - путь к директории, куда компилятор складывает файлы (по умолчанию «target/classes»);
    • ${project.name} - наименование проекта (можно ${pom.name});
    • ${project.version} - версия проекта (можно ${pom.version}).
  • Настройки. Доступ к свойствам settings.xml можно получить с помощью префикса settings
    • ${settings.localRepository} путь к локальному репозиторию.
  Рейтинг@Mail.ru