Maven: Профили сборки

Профили Maven позволяют иметь несколько конфигураций проекта в одном POM. Это удобно для переключения настроек под разные условия:

Что делают профили: переопределяют зависимости, плагины, свойства для специфических сред (например, для dev vs prod) или целей (отладочная сборка, сборка для CI).

Объявление: профили прописываются в секции <profiles> в pom.xml. Также профили могут быть определены в пользовательском файле настроек Maven (~/.m2/settings.xml) или глобально для всей Maven установки.

Активация: профиль можно активировать явным флагом -P (например, mvn package -Pdev) либо автоматически (профиль содержит условие <activation>: по имени ОС, наличию файла, свойству и т.д.).

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

Пояснение: Порой проект нужно собирать по-разному в разных ситуациях. Пример: у нас есть приложение, которое на тестовом окружении должно подключаться к встроенной базе данных и включать отладочный лог, а на продакшене – к кластеру PostgreSQL и иметь оптимизированные настройки. Можно, конечно, держать два разных POM-файла, но Maven предлагает элегантнее – профили внутри одного POM.
 
Как это выглядит: в pom.xml добавляется секция <profiles>, внутри нее один или несколько <profile>. У каждого профиля есть <id> (имя) и свои блоки, аналогичные структуре основного POM (можно внутри профиля писать <dependencies>, <build>, <properties> – эти вещи дополнят или переопределят основные). Например, профиль "prod" может добавить зависимость на реальную базу и убрать зависимость на встроенную. Или профиль "no-tests" может отключить запуск тестов (путем конфигурации плагина Surefire).
 
Активация профилей:

Ручная: разработчик указывает в командах Maven -P<имя> для включения (или -P!<имя> для исключения) профиля.


Автоматическая: в описании профиля можно задать условия <activation>. Например, <activeByDefault>true</activeByDefault> – профиль включается, если не указано обратное. Можно активировать по системе: <os><family>Windows</family></os> – профиль включится на Windows, но нет на Linux. Или <property><name>env</name><value>prod</value></property> – профиль активен, если запущено с параметром -Denv=prod или такая переменная определена.

Приоритеты и слияние: Если включено несколько профилей разом, их изменения к POM суммируются. Если они меняют одни и те же параметры, то последний в файле профиль может победить (но точно управлять порядком сложно, поэтому стараются избегать конфликтующих профилей). Профили в settings.xml могут включать настройки репозиториев, прокси и т.п., и могут автоматически применяться глобально, но профили, определенные в проекте, обычно важнее, так как специфичны для данного проекта.
 
Современная практика: профили используют ограниченно, чтобы не усложнять сборку. Например, профили удобно применять для:

Среда разработки vs Продакшен: разные конфиги, но сам код один. Например, профиль prod — сборка с оптимизациями, без отладочной информации.


Разные базы данных или контейнеры приложения: например, профили под разные серверы приложений, когда один POM должен уметь собирать вариант под Tomcat и вариант под Jetty (подключая разные зависимости).


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


CI/CD профили: иногда на CI включают профиль, который, скажем, генерирует дополнительные отчеты, сведенные в артефакты.

Важно: не стоит делать слишком много профилей и радикально различающихся сборок, иначе легко запутаться, какая версия приложения в итоге собирается. Maven-профили – инструмент для незначительных вариаций сборки. Для более серьезных различий иногда проще иметь несколько модулей или проектов.
 
Настройка профилей может происходить и вне pom.xml: файл ~/.m2/settings.xml может содержать секцию <profiles> для пользовательских профилей (например, настроек прокси, частных репозиториев). Их можно активировать глобально при запуске Maven (-P) или сделать активными всегда на данной машине. Но такие профили не распространяются на других – они локальны. В корпоративной среде чаще задают профили прямо в POM проекта или в родительском POM, чтобы все было под контролем версий.
Maven: Стандартная структура проекта
Слайд: Maven по умолчанию ожидает определенную структуру файлов и каталогов проекта (Convention over Configuration):

Исходный код приложения: src/main/java (пакеты соответствуют структуре директорий).


Ресурсы приложения (файлы конфигурации, статические ресурсы): src/main/resources (они попадут в класс-путь вместе с классами).


Тестовый код: src/test/java (автоматически компилируется и запускается при фазе тестирования).


Ресурсы тестов: src/test/resources.


Сборочные скрипты, Dockerfile и прочее (не по умолчанию, но часто хранят): в корне проекта или отдельной папке scripts.


Выходные артефакты (сгенерированные классы, JARы, отчеты): папка target (Maven создает ее сам при сборке).


Файл pom.xml – в корне проекта.

Пояснение: Одна из сильных сторон Maven – стандартная структура проекта. Если вы откроете любой Maven-проект, вы почти наверняка увидите одинаковую организацию каталогов. Это соглашение избавляет от необходимости конфигурировать пути в POM: Maven сам знает, где искать код и куда складывать результаты. Структура такова:
мой-проект/
├── pom.xml
├── src/
│   ├── main/
│   │   ├── java/        (Java исходники приложения)
│   │   ├── resources/   (некодовые ресурсы: *.properties, *.xml, статические файлы)
│   │   └── ... возможно другие папки (например, для WEB: webapp/)
│   └── test/
│       ├── java/        (тестовые исходники)
│       └── resources/   (ресурсы для тестов)
└── target/              (создается Maven: *.class, скомпилированные артефакты и пр.)
По умолчанию, если не менять настройки, Maven компилирует все .java из src/main/java и кладет результат (байткод .class) в target/classes. Любые файлы из src/main/resources он копирует в target/classes тоже (сохраняя структуру пакетов), так что они окажутся рядом с скомпилированными классами в итоговом JAR. То же с тестами: тестовый код компилируется из src/test/java в target/test-classes, а ресурсы тестов копируются туда же. Это позволяет плагину тестирования загрузить нужные файлы при выполнении тестов.
 
Если следовать этой структуре, большинство инструментов IDE (IntelliJ IDEA, Eclipse) автоматически распознают модули Maven: где код, где тесты. Средства статического анализа, генераторы тоже ожидают, что код здесь. В общем, жизнь сильно упрощается, когда все проекты структурированы одинаково.
 
Конечно, Maven допускает изменить пути (через плагины можно настроить свои директории). Но на практике это делают крайне редко – только при интеграции со старыми проектами или особыми требованиями. Стандартный подход: придерживаться дефолтной структуры. Это негласное соглашение среди Java-разработчиков: если проект на Maven/Gradle, его исходники лежат в src/main/java и т.д. Даже Gradle, о котором далее, по умолчанию использует ту же структуру, хотя теоретически мог бы иную – но сообщество выбрало переиспользовать успешный стандарт Maven.
 
Стоит заметить, что в Maven-модуле может быть и другая директория, например src/main/webapp для веб-артефактов (WAR): там хранятся HTML, JSP и веб-ресурсы. Maven-плагин для WAR знает про нее и упакует содержимое webapp в соответствующую структуру внутри WAR-файла. Но это частность, в целом же большинство проектов имеют вышеперечисленную структуру.
 
Современные практики полностью следуют этим соглашениям. Это значит, что перейдя в новый для себя Maven-проект, разработчик не тратит время на изучение структуры – она привычна. Следовательно, меньше конфигурации, меньше "магии" – все предсказуемо.
 
Если ваш проект состоит из нескольких модулей, структура повторяется для каждого модуля (каждый модуль — своя папка со своей src/... и pom.xml, а общий родитель в своем pom перечисляет модули). Но внутри модулей все унифицировано.