Apache Maven
(Часть 1): Основы

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

В Apache Maven данный принцип проявляется в том, что Maven предоставляет разумные настройки (готовые шаблоны) по умолчанию для управления сборкой проекта. Если они не подходят, то разработчик может переопределить их на свои.

Одной из таких настроек по умолчанию, например, является структура каталогов в Maven-проекте (подробнее о стандартных каталогах):

В этой структуре исходный код, в соответствии с соглашением, располагается в подкаталоге src/main/java. В каталоге test находится код тестов.

Аналогичным образом ресурсы, необходимые для приложения или его тестирования, находятся в каталоге resources.

Это всего лишь один из множества примеров стандартизации в соответствии с философией «Соглашение важнее конфигурации».

Maven использует объектную модель проекта (Project Object Model, POM) для управления проектом. Для описания модели обычно используется XML-документ, но возможны и другие форматы.

POM — это очень полезная и удобная вещь, которая описывает то, как будет собираться проект. Этот файл (обычно pom.xml) состоит из следующих частей:

Maven использует содержимое в POM для управления сборкой. Однако он также имеет стандартные значения по умолчанию. Таким образом, Maven несет ответственность за объединение значений по умолчанию и применение переопределений и дополнений, обнаруженных в pom-файле проекта.

Благодаря этому мы получаем:

Maven собирает свой POM, проходя слои, которые действуют как строительные блоки. Каждый используемый слой имеет возможность переопределять или дополнять содержимое того, что станет POM. Родительские файлы, спецификации и файлы POM-проекта — это то, где можно переопределить настройки Maven по умолчанию.

Теперь пройдемся по существующим слоям:

Этот слой находится в коде Maven. Если не предполагается править его исходник, то эти значения по умолчанию можно считать неизменяемыми.

Этот супер-POM также является частью кода Maven. Опять же, если цель не состоит в том, чтобы изменить исходник, то также можно считать, что Super POM является неизменяемым.

После установки Maven создает структуру каталогов. Одним из базовых каталогов является conf, содержащий файл глобальных настроек settings.xml. Поскольку этот файл существует на локальном компьютере, он доступен для редактирования. Как правило, любые параметры, которые применяются ко всем проектам, управляемым на конкретном компьютере, прописываются в этом глобальном settings.xml. Например, в этот файл входят такие параметры, как настройки прокси-сервера, URL-адреса корпоративных серверов, зеркала и т. д. В любом случае его не следует часто изменять.

Расположение:
Unix/MacOS: <maven installation>/conf/settings.xml
Windows: <maven installation\conf\settings.xml

Аналогично глобальным настройкам, но в другом месте, можно создать файл пользовательских настроек. Этот файл также называется settings.xml, но его местоположение находится в папке пользователя (user home) в каталоге .m2 (скрытая папка). Данный файл предназначен для настройки любых параметров, применимых к проектам. Управляется конкретным пользователем (на данном компьютере может быть несколько пользователей). Это могут быть имена пользователей и пароли для подключения к сети, параметры репозитория и т. д.

Расположение:
Unix/MacOS: <user.home>/.m2/settings.xml
Windows: <user.home>\.m2\settings.xml

Maven позволяет наследовать содержимое от родительского POM и характеристики версий из pom-спецификации. Обычно родительские POM содержат повторно используемые зависимости, плагины и свойства, используемые POM проекта. POM-спецификации (Bill-of-Material — BOM) — это специализированный POM, который позволяет группировать версии зависимостей. Использование POM-спецификации избавляет разработчика от необходимости проверять совместимость различных зависимостей. Изменение любого из них возможно, если есть необходимость и право на изменение. Поскольку изменения в любом из них могут повлиять на несколько других проектов, для изменений рекомендуется соответствующее увеличение версий и их пересмотр.

Расположение:
Различные места на компьютере или в каком-либо репозитории.

Это Project Object Model для проекта. В этом месте подробно описаны инструкции Maven для конкретного проекта. Типичное содержимое включает в себя: уникальный набор координат, используемых для идентификации проекта; название и описание проекта; набор разработчиков, связанных с проектом; любые сведения об управлении системой контроля версиями; все зависимости и плагины для конкретного проекта; любые профили, которые позволяют поочередно выполнять Maven в этом проекте и так далее. Все это будет описано в последующих статьях. Файл, содержащий этот POM, называется pom.xml, но можно использовать и другие имена. Если используется альтернативное имя, то исполняемому файлу Maven необходимо будет указать имя файла для выполнения.

Расположение:
Unix/MacOS: $PROJECT/pom.xml
Windows: $PROJECT\pom.xml

Существуют сотни или тысячи проектов, которые собраны в артефакты. Некоторые из этих артефактов потенциально могут быть использованы в текущем проекте в качестве библиотек. Например, проект может зависеть от логирования или библиотеки JSON. В центральном репозитории можно разместить множество артефактов зависимостей. Основное такое хранилище Maven называется Maven Central. Существует также множество других подобных хранилищ.

Следующий вопрос заключается в том, как определить и загрузить точные артефакты, необходимые для проекта? Правильный способ идентифицировать артефакт — это использовать его координаты Maven.

Это способ уникальной идентификации артефакта. Существуют три основные координаты, которые используются для идентификации артефакта.

Классификация по группе, обычно относящаяся к организации или компании и может иметь общее название для одного или нескольких проектов. groupId обычно описан через точку (аналогично имени пакета Java). Каждый элемент в этой точечной нотации соответствует каталогу в древовидной структуре хранилища. Например, groupId в org.apache.commons соответствует $REPO/org/apache/commons.

Наличие точечной нотации не является обязательным требованием (хотя очень рекомендуется).

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

Артефакт проявляется в виде подкаталога в дереве каталогов, представленного groupId. Например, artifactId commons-lang3 в groupId org.apache.commons сообщает, что артефакт можно найти в разделе: $REPO/org/apache/commons/commons-lang3/.

Это идентификатор, который отслеживает уникальные сборки артефакта. Версия — это строка, созданная разработчиками проекта для определения набора изменений, внесенных в предыдущее создание артефакта того же проекта. Настоятельно рекомендуется следовать схемам семантического управления версиями, хотя это не обязательно.

Версия проявляется в виде подкаталога в дереве каталогов, который состоит из groupId и artifactId. Например, version 3.1.0 для artifactId commons-lang3 в groupId org.apache.commons обозначает, что артефакт находится в $REPO/org/apache/commons/commons-lang3/3.1.0/.

Теперь немного подробнее про версии.

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

Во время разработки продукта может быть создано несколько артефактов, которые можно протестировать, проверить и т. д. Этот цикл разработки обычно создает артефакты с той же версией, что и предыдущие сборки на том же этапе. Основанием для этого утверждения является то, что релиз все еще находится в экспериментальном, бета- или альфа-состоянии, но может претерпеть дополнительные изменения. Однако трудно заставить все проекты постоянно обновлять свои собственные POM для каждой такой сборки. В этой проблеме помогает создание SNAPSHOT’ов (снимков).

Например, для проекта A версии 1.0.0 команда разработчиков может создать несколько версий SNAPSHOT’ов с версией 1.0.0-SNAPSHOT в течение определенного периода времени. Этот суффикс подразумевает, что номер версии в конце должен быть 1.0.0, однако при каждой сборке будут создаваться новые артефакты, которые заменят предыдущий SNAPSHOT. Более новый SNAPSHOT может заменить существующий SNAPSHOT артефакта в репозитории Maven, поэтому пользовательские проекты могут безопасно получить последнюю версию SNAPSHOT’а. SNAPSHOT — это изменяемая версия проекта, которая может быть объявлена как зависимость в пользовательских проектах.

Готово для выпуска в продакшн (Production-Ready)

После завершения всего тестирования POM больше не нуждается в суффиксе SNAPSHOT и может создать готовую к продакшену неизменяемую версию проекта. Как только она будет помещена в репозиторий, в нее нельзя вносить никаких дальнейших изменений (Maven не позволяет это делать по своим внутренним правилам). Обычно можно найти другие готовые к производству суффиксы: 1.0.0-GA (общая доступность) или 1.0.0-RELEASE (выпущенный артефакт) или 1.0.0-FINAL и т. д. Опять же, строки версий вообще не имеют значения для Maven.

Распространенный способ передачи координат артефактов — это разделение двоеточием. Вместе координаты называются Group-Artifact-Version или координатами GAV. Координаты GAV для commons-lang3 версии 3.1.0 будут следующими: org.apache.commons:commons-lang3:3.1.0.

Часто сборка проекта может включать более одного формата артефактов. Выполнение Maven в проекте может привести к созданию jar, zip, архива и многих других артефактов. Выполнение также может выдавать различные выходные данные, такие как двоичный код, zip-файл исходных текстов, zip файлов javadoc и т. д.

classifier используется для разграничивания альтернативного вывода, получаемого при выполнении Maven в POM проекта. Распространенные примеры включают источники в виде файла jar/zip и javadoc в виде файла jar/zip. classifier задается как часть имени артефакта. Для нашего приведенного выше примера commons-lang3 артефакт, который нужно искать, таков: commons-lang3−3.10-javadoc.jar или commons-lang3−3.10-sources.jar в $REPO/org/apache/commons/commons-lang3/3.1.0/.

type используется для разграничивания формата артефакта. Артефакты, создаваемые в результате выполнения Maven, могут быть различных типов, как уже обсуждалось: .jar, .war, .zip и т. д. Иногда для проекта может быть полезно создавать артефакты в разных форматах. Эти форматы указаны в type.

Комбинация GAV-координат и различителей может использоваться для определения точного артефакта, необходимого для проекта.

Этот раздел описывает иерархию в POM’ах в Maven.

Родительский POM — это POM, от которого текущий POM проекта может наследовать содержимое. POM проекта может зависеть только от одного родительского POM. Это наследование от одного родителя является односторонним. Родительский POM не знает о POM, который наследуется от него. Дочерний POM заявляет о своем происхождении по своему pom.xml.

Любое количество POM может объявить другой POM своим родителем.

Примечание: родительский POM можно использовать для объявления повторно используемых частей POM, которые затем могут унаследовать отдельные дочерние POM. Это помогает как в обслуживании, так и в уменьшении беспорядка.

POM-агрегатор (также известный как POM-реактор) — это POM, который может упорядочивать сборки многих проектов. POM-агрегатор определяет все проекты, которыми можно управлять при сборке вместе. Дочерние POM'ы остаются в неведении о POM-агрегаторе, который его вызывает. Дочерний POM может быть указан в нескольких POM-агрегаторах. POM-агрегатор перечисляет дочерние POM'ы по name (имени) в своем собственном pom.xml в качестве module (модуля).

Как следует из объявленного модуля, этот шаблон предназначен для модульных сборок проектов. Нет наследования какого-либо содержимого от POM-агрегатора.

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

POM-спецификация — это POM, который может объявлять наборы зависимостей, которые были протестированы для их совместной работы. Обилие артефактов и версий каждого из них иногда может привести к путанице и потребности в механизмах проб и ошибок для определения совместимости и/или правильной функциональности.

POM-спецификация уменьшает эти хлопоты. POM-спецификация также является средством множественного наследования, поскольку POM проекта может импортировать несколько POM-спецификаций. POM-спецификация не знает о дочерних POM’ах, которые его импортируют. Дочерние POM’ы объявляют спецификацию POM’е проекта.

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

POM может быть как родителем (parent), так и агрегатором (aggregator). Это обеспечивает двустороннюю связь в тесно связанном наборе модулей, которые зависят от общего набора унаследованного содержания.