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

Введение
Apache Maven (обычно называют просто Maven) — это фреймворк по автоматизации и управлению сборкой Java-приложений. Слово Maven взято из языка идиш, примерный перевод которого можно выразить как «собиратель знания» (accumulator of knowledge), «эксперт».
Apache Maven, по большей части, написан на Java. Это проект с открытым исходным кодом, который следует философии «соглашение важнее конфигурации» (convention over configuration).
1. Основные возможности Maven
Наиболее важные возможности Maven:
  • Простая настройка проекта в соответствии с лучшими практиками
  • Управление зависимостями, включая автоматическое обновление
  • Возможность работать с несколькими проектами одновременно
  • Большое хранилище библиотек и метаданных для использования из коробки
  • Расширяемость с возможностью написания своих плагинов
  • Создание сайта и PDF с документацией
  • Проверка корректности структуры проекта
  • Компиляция исходного кода, отображение ошибок/предупреждений
  • Тестирование проекта на основе уже написанных тестов
  • Упаковка скомпилированного кода в артефакты (например, .jar, .war, .ear, .zip-архивы и многое другое)
  • Упаковка исходного кода в загружаемые архивы/артефакты
  • Установка упакованных артефактов на сервер для последующего развертывания (деплоя) или в репозиторий для распространения
  • Создание отчетов по тестированию
  • Сообщение об удачной/неудачной сборке проекта
2. Принцип "соглашение важнее конфигурации"
Соглашение важнее конфигурации — это принцип проектирования программного обеспечения целью которого является уменьшение количества лишних действий, необходимых разработчику при создании своего проекта.
В Apache Maven данный принцип проявляется в том, что Maven предоставляет разумные настройки (готовые шаблоны) по умолчанию для управления сборкой проекта. Если они не подходят, то разработчик может переопределить их на свои.
Одной из таких настроек по умолчанию, например, является структура каталогов в Maven-проекте (подробнее о стандартных каталогах):
В этой структуре исходный код, в соответствии с соглашением, располагается в подкаталоге src/main/java. В каталоге test находится код тестов.
Аналогичным образом ресурсы, необходимые для приложения или его тестирования, находятся в каталоге resources.
Это всего лишь один из множества примеров стандартизации в соответствии с философией «соглашение важнее конфигурации».
3. Как работает Maven?
Maven использует объектную модель проекта (POM, Project Object Model) для управления проектом. Для описания модели обычно используется XML-документ, но возможны и другие форматы.
Рисунок, иллюстрирующий типичную работу Maven
4. Что такое Объектная модель проекта (POM)?
POM — это очень полезная и удобная вещь, которая описывает то, как будет собираться проект. Этот файл (обычно pom.xml) состоит из следующих частей:
  • Project coordinates (координаты проекта) — однозначно идентифицируемый набор свойств, с помощью которых артефакты проекта могут быть использованы в другом месте
  • Dependencies (зависимости) — библиотеки и код, необходимые для сборки проекта
  • Plugins (плагины) — вспомогательные инструменты при сборке проекта
  • Properties (свойства) — общие значения, необходимые проекту
  • Inheritance details (детали наследования) — возможность создания иерархии для повторно используемых компонентов POM
  • Profiles (профили) — альтернативные пути сборки проекта, разбитые по профилям
4.1. Как Maven взаимодействует с POM?
Maven использует содержимое в POM для управления сборкой. Однако он также имеет стандартные значения по умолчанию. Таким образом, Maven несет ответственность за объединение значений по умолчанию и применение переопределений и дополнений, обнаруженных в pom-файле проекта.
Благодаря этому мы получаем:
  • совокупность шагов выполнения, свойств и профилей
  • контент, который Maven может выполнить для проекта
  • исчерпывающий набор зависимостей и плагинов, необходимых для такого выполнения
  • определение любых переходных зависимостей (например, зависимости зависимостей)
  • разрешение конфликтов с точки зрения версий зависимостей
4.2. Как Maven собирает POM?
Maven собирает свой POM, проходя слои, которые действуют как строительные блоки. Каждый используемый слой имеет возможность переопределять или дополнять содержимое того, что станет POM. Родительские файлы, спецификации и файлы POM-проекта — это то, где можно переопределить настройки Maven по умолчанию.
5. Слои
Теперь пройдемся по существующим слоям:
Внутренние настройки Maven
Этот слой находится в коде Maven. Если не предполагается править его исходник, то эти значения по умолчанию можно считать неизменяемыми.
Maven Super POM
Этот супер-POM также является частью кода maven. Опять же, если цель не состоит в том, чтобы изменить исходник, то также можно считать, что Super POM является неизменяемым.
Глобальные настройки Maven
После установки Maven создает структуру каталогов. Одним из базовых каталогов является conf, содержащий файл глобальных настроек settings.xml. Поскольку этот файл существует на локальном компьютере, он доступен для редактирования. Как правило, любые параметры, которые применяются ко всем проектам, управляемым на конкретном компьютере, прописываются в этом глобальном settings.xml. Например, в этот файл входят такие параметры, как настройки прокси-сервера, URL-адреса корпоративных серверов, зеркала и т. д. В любом случае его не следует часто изменять.
Расположение:
Unix/MacOS: <maven installation>/conf/settings.xml
Windows: <maven installation\conf\settings.xml
Пользовательские настройки Maven
Аналогично глобальным настройкам, но в другом месте, можно создать файл пользовательских настроек. Этот файл также называется settings.xml, но его местоположение находится в папке пользователя (user home) в каталоге .m2 (скрытая папка). Данный файл предназначен для настройки любых параметров, применимых к проектам. Управляется конкретным пользователем (на данном компьютере может быть несколько пользователей). Это могут быть имена пользователей и пароли для подключения к сети, параметры репозитория и т. д.
Расположение:
Unix/MacOS: <user.home>/.m2/settings.xml
Windows: <user.home>\.m2\settings.xml
Родительские POM'ы / спецификации
Maven позволяет наследовать содержимое от родительского POM и характеристики версий из pom-спецификации. Обычно родительские POM содержат повторно используемые зависимости, плагины и свойства, используемые POM проекта. POM-спецификации (Bill-of-Material — BOM) — это специализированный POM, который позволяет группировать версии зависимостей. Использование POM-спецификации избавляет разработчика от необходимости проверять совместимость различных зависимостей. Изменение любого из них возможно, если есть необходимость и право на изменение. Поскольку изменения в любом из них могут повлиять на несколько других проектов, для изменений рекомендуется соответствующее увеличение версий и их пересмотр.
Расположение:
Различные места на компьютере или в каком-либо репозитории.
Project POM
Это Project Object Model для проекта. В этом месте подробно описаны инструкции Maven для конкретного проекта. Типичное содержимое включает в себя: уникальный набор координат, используемых для идентификации проекта; название и описание проекта; набор разработчиков, связанных с проектом; любые сведения об управлении системой контроля версиями; все зависимости и плагины для конкретного проекта; любые профили, которые позволяют поочередно выполнять Maven в этом проекте и так далее. Все это будет описано в последующих статьях. Файл, содержащий этот POM, называется pom.xml, но можно использовать и другие имена. Если используется альтернативное имя, то исполняемому файлу Maven необходимо будет указать имя файла для выполнения.
Расположение:
Unix/MacOS: $PROJECT/pom.xml
Windows: $PROJECT\pom.xml
6. Координаты зависимостей
Существуют сотни или тысячи проектов, которые собраны в артефакты. Некоторые из этих артефактов потенциально могут быть использованы в текущем проекте в качестве библиотек. Например, проект может зависеть от логирования или библиотеки JSON. В центральном репозитории можно разместить множество артефактов зависимостей. Основное такое хранилище Maven называется Maven Central. Существует также множество других подобных хранилищ.
Следующий вопрос заключается в том, как определить и загрузить точные артефакты, необходимые для проекта? Правильный способ идентифицировать артефакт — это использовать его координаты Maven.
Что такое координаты Maven?
Это способ уникальной идентификации артефакта. Существуют три основные координаты, которые используются для идентификации артефакта.
groupId
Классификация по группе, обычно относящаяся к организации, компании и может иметь общее название для одного или нескольких проектов. groupId обычно описан через точку (аналогично имени пакета Java). Каждый элемент в этой точечной нотации соответствует каталогу в древовидной структуре хранилища. Например, groupId в org.apache.commons соответствует $REPO/org/apache/commons.
Наличие точечной нотации не является обязательным требованием (хотя очень рекомендуется).
artifactId
Это точное название проекта. Среди множества проектов, существующих в группе, artifactId может однозначно идентифицировать артефакт. Если название состоит из нескольких слов, то в описании artifactId оно разделяется дефисами. В идеале, имена должны быть небольшой длины.
Артефакт проявляется в виде подкаталога в дереве каталогов, представленного groupId. Например, artifactId commons-lang3 в groupId org.apache.commons сообщает, что артефакт можно найти в разделе: $REPO/org/apache/commons/commons-lang3/.
version
Это идентификатор, который отслеживает уникальные сборки артефакта. Версия — это строка, созданная разработчиками проекта для определения набора изменений, внесенных в предыдущее создание артефакта того же проекта. Настоятельно рекомендуется следовать схемам семантического управления версиями, хотя это не обязательно.
Версия проявляется в виде подкаталога в дереве каталогов, который состоит из 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.
Система координат GAV
Распространенный способ передачи координат артефактов — это разделение двоеточием. Вместе координаты называются Group-Artifact-Version или координатами GAV. Координаты GAV для commons-lang3 версии 3.1.0 будут следующими: org.apache.commons:commons-lang3:3.1.0.
Дополнительные различители
Часто сборка проекта может включать более одного формата артефактов. Выполнение Maven в проекте может привести к созданию jar, zip, архива и многих других артефактов. Выполнение также может выдавать различные выходные данные, такие как двоичный код, zip-файл исходных текстов, zip файлов javadoc и т. д.
Таким образом, помимо вышеупомянутых координат GAV, для идентификации таких разнообразных результатов необходимы различители.
classifier
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
type используется для разграничивания формата артефакта. Артефакты, создаваемые в результате выполнения Maven, могут быть различных типов, как уже обсуждалось: .jar, .war, .zip и т. д. Иногда для проекта может быть полезно создавать артефакты в разных форматах. Эти форматы указаны в type.
Собираем все вместе
Комбинация GAV-координат и различителей может использоваться для определения точного артефакта, необходимого для проекта.
Иерархия POM
Этот раздел описывает иерархию в POM’ах в Maven.
Родительский POM
Родительский 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-агрегатор перечисляет дочерние POM’ы по name (имени) в своем собственном pom. xml в качестве module (модуля).
Как следует из объявленного модуля, этот шаблон предназначен для модульных сборок проектов. Нет наследования какого-либо содержимого от POM-агрегатора.
Примечание: POM-агрегатор можно использовать для обеспечения последовательности сборок и ведения списка проектов, которыми следует управлять совместно.
Спецификация POM (Bill-Of-Materials)
POM-спецификация — это POM, который может объявлять наборы зависимостей, которые были протестированы для их совместной работы. Обилие артефактов и версий каждого из них иногда может привести к путанице и потребности в механизмах проб и ошибок для определения совместимости и/или правильной функциональности.
POM-спецификация уменьшает эти хлопоты. POM-спецификация также является средством множественного наследования, поскольку POM проекта может импортировать несколько POM-спецификаций. POM-спецификация не знает о дочерних POM’ах, которые его импортируют. Дочерние POM’ы объявляют спецификацию POM’е проекта.
Примечание: POM-спецификацию можно использовать для объединения хорошо работающих зависимостей (с правильными версиями) вместе, чтобы избежать повторения для каждого проекта.
POM может быть как родителем (parent), так и агрегатором (aggregator). Это обеспечивает двустороннюю связь в тесно связанном наборе модулей, которые зависят от общего набора унаследованного содержания.
Оцените статью, если она вам понравилась!