Maven: POM (Project Object Model)

POM (pom.xml) – центральный XML-файл конфигурации Maven-проекта. В нем описано:

Идентификация проекта: <groupId>, <artifactId>, <version> – уникальные координаты артефакта. Например, com.mycompany:my-app:1.0.0.

Основные сведения: <name> (название проекта), <description> (описание), <url> (сайт/репозиторий проекта).

Тип упаковки: <packaging> – тип создаваемого артефакта: по умолчанию jar (может быть war для веб-приложений, pom для объединения модулей и др.).

Зависимости: секция <dependencies> содержит список необходимых библиотек с указанием их координат и, при необходимости, области видимости (scope).

Управление зависимостями: <dependencyManagement> – объявление версий зависимостей для наследников или модулей (полезно в многомодульных проектах для унификации версий).

Сборка и плагины: <build> – настройки процесса сборки, включая список подключаемых Maven-плагинов (<plugins>) и ресурсные директории (<resources>).

Профили сборки: <profiles> – определение альтернативных конфигураций сборки для различных сред (dev, test, prod и др.).

Наследование: <parent> – ссылка на родительский POM, от которого текущий проект может наследовать зависимости и настройки (часто используется корпоративный или Spring Boot “starter” POM как родитель).

Пояснение: Abbreviation POM расшифровывается как Project Object Model. Файл pom.xml действительно сердце Maven-проекта. Рассмотрим основные элементы POM подробнее:

GroupId, ArtifactId, Version: Эти три поля определяют уникальный координат артефакта. Например, для библиотеки Spring Core это org.springframework:spring-core:5.3.30. GroupId обычно указывает организацию или группу проектов (часто соответствует доменному имени организации в обратном порядке, например, com.fasterxml.jackson), ArtifactId – имя конкретного проекта/библиотеки, Version – номер версии. В совокупности получается уникальный ключ. Когда Maven скачивает артефакт, он сохраняет его по пути, соответствующему этим координатам (например, ~/.m2/repository/org/springframework/spring-core/5.3.30/spring-core-5.3.30.jar). При выпуске новой версии библиотеки версия меняется, и артефакт считается другим.


Packaging: Определяет формат выхода сборки. По умолчанию Maven-проекты имеют packaging = jar (Java-библиотека). Если вы пишете веб-приложение для деплоя на сервер, указывают war – тогда Maven упакует код и ресурсы в Web Archive. Есть тип pom – особый случай: проект-родитель или агрегатор, не производящий исполняемый код, а лишь объединяющий модули или определяющий общие зависимости.


Name, Description, URL: Метаданные проекта. Они не влияют на сборку, но используются для человеческого понимания и при публикации артефакта – эти сведения можно увидеть на сайте репозитория (например, на Maven Central будет отображаться имя и описание).


Dependencies: Внутри <dependencies> перечисляются все библиотеки, которые нужны проекту. Для каждой указываются groupId, artifactId, version. Можно также указать <scope> – область применения зависимости:


Например, compile (по умолчанию) – необходима при компиляции и включается в финальный артефакт;


test – нужна только для тестирования (например, JUnit), в продуктовый JAR не попадает;


provided – нужна при компиляции, но не включается в артефакт, т.к. предполагается, что она будет предоставлена окружением (типичный пример – сервлет API для веб-приложений, которое предоставляется контейнером сервлетов).


runtime – нужна только во время выполнения (например, JDBC-драйвер).

Maven автоматически подтягивает транзитивные зависимости: если библиотека А зависит от Б, то Maven включит Б тоже (можно управлять транзитивными зависимостями, исключая или фиксируя версии через механизмы <exclusions> и <dependencyManagement>).

Dependency Management: Эта секция полезна в многомодульных проектах или когда есть множество зависимостей. В <dependencyManagement> можно задать версии библиотек централизованно. Дочерние модули могут в своих <dependencies> упоминать зависимость без версии – они наследуют версию, определенную в разделе управления зависимостями родительского POM. Это обеспечивает единообразие версий. Также многие фреймворки (Spring Boot, Jakarta EE BOM и др.) публикуют BOM-POM’ы: их можно подключить как <dependencyManagement> импорт, и они задают рекомендуемые совместимые версии целого набора связанных библиотек.


Build (Plugins, Resources): В секции <build> настраиваются детали сборки. Сам Maven фазы выполняет, но конкретные действия реализуют плагины. Например, компиляцию Java-кода выполняет плагин maven-compiler-plugin, упаковку JAR – maven-jar-plugin, запуск тестов – maven-surefire-plugin. Многие из них Maven подключает автоматически с настройками по умолчанию. Однако, если нужны особые настройки (например, компилировать под Java 17, включить параметры компилятора, дополнительно паковать что-то в JAR), в <plugins> можно добавить соответствующие плагины и конфигурации для них. Resources – указание дополнительных ресурсов, которые надо скопировать в выходной класс-путь (по умолчанию это src/main/resources). Обычно можно не менять, если структура стандартная.
 
Также в <build> можно указать <finalName> для имени выходного файла, <plugins> мы уже обсудили, <repositories> (внутри build) – реже используется, чаще глобально, но тоже возможно, <distributionManagement> – куда деплоить артефакт (например, URL вашего Nexus для mvn deploy), и прочие тонкие настройки сборки.


Profiles: Maven-профили позволяют иметь несколько конфигураций сборки внутри одного POM. Например, вы можете определить профиль "dev" и "prod", которые отличаются набором подключаемых библиотек или плагинов. Профиль может активироваться вручную (mvn install -Pdev) или автоматически при выполнении определенных условий (по ОС, наличию файла, значению переменной среды и т.п.). Внутри <profiles> каждый <profile> может переопределять зависимости, плагины, свойства для своего сценария. Современная практика – использовать профили для отличий между средами (например, разные базы данных для разработки и продакшена) или для опциональных частей сборки (например, включение интеграционных тестов). Однако важно не злоупотреблять профилями – базовый POM должен успешно собирать приложение, а профили только добавляют специфичные настройки.


Parent POM: В Maven можно строить древовидную структуру проектов. Родительский POM позволяет вынести общие зависимости и плагины в один файл, а дочерние модули будут их наследовать. Например, в организации можно определить корпоративный родительский POM, где сразу заданы версии десятков библиотек, плагинов, общие профили (настройки проверки кода, деплой и т.д.). Каждый новый сервис компании просто наследует этот POM – и получает все стандартные зависимости и правила, переопределяя лишь специфичное. Еще случай: многомодульный проект – у родителя packaging pom и он перечисляет модули, а каждый модуль – отдельный <module> со своим POM, наследующим от родителя. Maven при сборке таком проекта запустит сборку всех модулей последовательно (или параллельно, если указать опцию). Parent POM – мощный инструмент для поддержания согласованности в больших проектах.

Практически, pom.xml типичного Maven-проекта довольно лаконичен, т.к. многое работает по умолчанию. Пример минимального POM для приложения:
<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example.myapp</groupId>
  <artifactId>demo-app</artifactId>
  <version>1.0.0</version>
  <packaging>jar</packaging>
  
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
      <version>3.1.2</version>
    </dependency>
  </dependencies></project>
Даже без раздела <build> Maven по умолчанию скомпилирует Java-код (поддерживая версию Java, которая настроена в плагине компилятора по умолчанию, или можно добавить <maven.compiler.target> в свойствах), запустит тесты и упакует JAR. Разработчику остается только при необходимости расширять этот POM дополнительными зависимостями и настройками. Таким образом, POM в Maven – это единая декларация вашего проекта, вокруг которой строится весь остальной процесс.
Maven: Жизненный цикл сборки
Слайд: Maven реализует сборку проекта как последовательность фаз, объединенных в жизненные циклы. Существует 3 основных цикла:

Clean: подготовка к сборке – удаляет результаты предыдущих сборок. Фазы: pre-clean, clean, post-clean (обычно выполняется mvn clean для очистки папки target).


Default (Build): основной цикл, выполняющий сборку и упаковку. Ключевые фазы: validate, compile, test, package, verify, install, deploy. Каждая фаза отвечает за свой шаг (от проверки проекта до развертывания).


Site: генерация документации сайта проекта. Фазы: pre-site, site, post-site, site-deploy (используется для публикации отчетов, javadoc и пр.).

Особенности Maven: при вызове фазы выполняются все предшествующие. Например, команда mvn package запустит и validate, и compile, и test и т.д. вплоть до package. Команда mvn install включает все фазы вплоть до установки артефакта в локальный репозиторий.
 
Пояснение: Жизненный цикл Maven – это упорядоченный набор фаз, через которые проходит сборка. Maven определяет три базовых цикла: clean, default (иногда называют build) и site. Обычно разработчики работают с первыми двумя.

Clean Lifecycle: отвечает за очистку проекта. Когда мы вызываем mvn clean, Maven заходит в цикл clean и выполняет фазу clean, задача которой – удалить каталог target (куда Maven складывает скомпилированные классы, JAR-файлы и прочий выход). Таким образом, clean гарантирует, что последующая сборка начнется с чистого состояния. Pre-clean и post-clean редко переопределяются, но они существуют для расширяемости (например, если вдруг нужно выполнить какие-то шаги до или после очистки – это можно настроить плагинами на эти фазы).


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


validate – проверка корректности проекта: все ли необходимые описания есть, корректны ли значения, обычно не требует плагинов, просто встроенные проверки Maven.


compile – компиляция исходного кода (mvn compile скомпилирует Java-файлы в .class и поместит в target/classes).


test – запуск юнит-тестов (используя плагин Surefire по умолчанию, который ищет тесты и запускает их). Результаты тестов обычно появятся в виде отчетов в target/surefire-reports.


package – упаковка скомпилированного кода в артефакт (например, создание JAR или WAR файла в папке target). Если это библиотека, будет JAR; если веб-приложение – WAR; можно настроить и другие форматы.


verify – валидация результатов интеграционных тестов или других критериев качества, если таковые настроены. Часто неявно, но может использоваться для дополнительных проверок (напр., плагин failsafe для интеграционных тестов работает на фазах integration-test и verify).


install – установка артефакта в локальный Maven-репозиторий (~/.m2/repository). mvn install полезен, когда вы хотите сделать собранный артефакт доступным другим вашим проектам на этом же компьютере (они смогут его взять как зависимость).


deploy – развертывание артефакта во внешнее хранилище (например, загрузка в удаленный Nexus/Artifactory или на Maven Central, если у вас настроены права). Обычно mvn deploy запускается в CI на этапе публикации релиза.

Разработчики обычно запускают mvn clean install во время локальной работы (очистить и собрать + установить локально). На CI/CD сервере, напротив, могут выполнить mvn clean deploy для сборки и публикации результата. Понимание фаз важно: если, к примеру, вы запустите mvn test, Maven выполнит validate, compile и затем test (но не станет упаковывать или устанавливать). А вот mvn package прогонит все вплоть до package (включая тесты), но не выполнит install и deploy.

Site Lifecycle: менее популярный цикл, предназначенный для создания документации о проекте. Maven может на основе конфигурации генерировать веб-сайт проекта с отчетами, javadoc и прочим. Фаза site создает статические страницы в target/site, а site-deploy может скопировать их на сервер (если настроен, например, FTP или GitHub Pages). Сейчас этот механизм используется редко, так как многие проекты перешли на генерацию документации через отдельные инструменты или CI.

В Maven плагины "привязываются" к определенным фазам. Например, maven-compiler-plugin по умолчанию привязан к фазе compile, surefire-plugin – к фазе test, maven-jar-plugin – к package, и т.д. Когда Maven доходит до соответствующей фазы, он запускает метод (goal) плагина. Если вы хотите изменить поведение – например, запустить дополнительный скрипт после упаковки – вы могли бы привязать свой плагин к фазе package или verify.
 
Современные практики: разработчики, как правило, не вызывают напрямую фазы ниже package – то есть редко делают mvn compile или mvn test отдельно, а сразу запускают полный цикл mvn clean install (который включает все и останавливается на install). Это гарантирует, что у вас и код скомпилирован, и тесты прошли, и артефакт готов. Для быстрого цикла разработки можно и ограничиться mvn compile или mvn test (IDE часто сами вызывают нужные фазы при запуске). В больших проектах Maven позволяет выполнять сборку модулей в параллель (mvn -T 4 install – 4 потока), что ускоряет сборку на многоядерных машинах. Но параллельность ограничена независимостью модулей (сначала строятся те, от которых зависят другие).
 
Итак, жизненный цикл Maven – концепция строгой последовательности шагов. Это отличается от Gradle, где, как увидим, сборка определяется графом задач, а не линейной последовательностью фаз.