Профили в Maven.

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

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

Допустим, у вас есть обычный проект с поддержкой Maven. И его файл pom.xml кратко выглядит примерно так:

Все базовые атрибуты проекта здесь — groupId(идентификатор группы разработчиков), artifactId(наименование продукта), version(номер версии), а также все нужные зависимости.

Теперь допустим, что ваш проект состоит из нескольких модулей:

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

Итак, профили задаются все в том же файле pom.xml внутри тегов <profiles></profiles>. Каждый профиль (внутри тега <profile>) имеет свой идентификатор и способ активации. Способ активации как раз и означает то, когда активируется именно этот профиль. Например, под разные операционные системы у вас должны использоваться разные наборы графических библиотек. Способы активации задаются внутри тега <activation>. В нашем случае девелоперский профиль содержит тег <activateByDefault> и прописанное внутри него значение true. Это означает, что по умолчанию проект будет запускать с использованием той конфигурации, которая задана в этом профиле.

Для каждого профиля также прописываются все нужные модули. В первом случае — это обычный режим запуска сборки, а во втором — запуск дополнительно ui-тестов.

Чтобы запустить проект Maven с указанным профилем достаточно указать его (или их) в качестве параметров команды mvn clean install -P<profile_name>:

Также в Intelij Idea вы можете увидеть доступные профили, запустив панель Maven. Это можно сделать, вызвав View -> Tool Windows -> Maven Projects. У меня под рукой был другой запущенный проект и в нем существовало три нужных мне профиля:

Настройка источников данных для разных профилей.

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

Создайте файл настроек для подключения к базе данных, создав файл db.properties.

Это обычный файл .properties, содержащий перечень необходимых ключей для подключения к базе данных. Я положил его в директорию src/main/resources. Но вместо значений мы видим выражения вида ${<name>}. В процессе сборки Maven заменит их соответствующими значениями из профилей, описанными ниже:

Новый код выделен красным. Внутри каждого из профилей используется тег <properties>. Таким образом,  мы фактически задаем все нужные для этого профиля настройки подключения. Но что дальше? Теперь нам необходимо как-то связать настройки из профиля с файлом db.properties, чтобы подставить туда нужные значения.

Процесс подстановки значений в терминах Maven называется фильтрацией или filtering. Осталось только указать Maven‘у в каких файлах следует произвести подстановку значений.

Для этого добавим в наш pom.xml файл тег <build>, а внутри него опишем ту директорию, в которой лежит нужный нам файл(напомню, что это папка src/main/resources):

Внутри тега <flitering> мы прописываем true. Теперь в момент сборки Maven просканирует все хранящиеся в данной директории файлы и, например, вместо выражения ${db.username} подставит одноименное значение, указанное в профиле.

Допустим мы запускаем сборку с профилем test, что равнозначно исполнению команды:

Теперь все значения в файле db.properties будут замещены одноименными значениями из тега <properties> в профиле test. Например, вместо db.driver = ${db.driver} появится db.driver = com.mysql.jdbc.Driver.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *