Сегодня я хотел бы поделиться с Вами информацией по профилям в Мавен. Это действительно очень полезная вещь в арсенале каждого программиста. И сейчас посмотрим почему же.
Шаг 0. Введение
Приходилось ли Вам когда нибудь заводить несколько аккаунтов разных типов, чтобы получить больше возможностей? Заводил ли кто-то из Вас несколько страничек в социальной сети для того, чтобы общаться с одной, а с второй просто послушать музыку или других своих целях?
Вместить все это в одном профиле или постоянно переписывать информацию или делать чистку и добавление друзей(что не совсем хорошо скажется на Вашей репутации) не совсем хорошо и удобно. А удобно и быстро – это одно из главных правил программиста. Все должно быть автоматизировано. Сегодня мы поговорим именно о том, как применить профили в Maven.
Шаг 1. Моделируем задачу
Когда разрабатывается та или иная система у нас есть часть для того чтобы проводить тестирование и развертывание (если это веб приложение) на своем сервере со своими настройками. То есть все настройки меняются в зависимости от Enviroment. Давайте создадим себе задачу для поиска лучшего решения. Я б хотел рассмотреть несколько из:
1. У нас есть система с настройками сервера приложений на котором будет развернуто наше приложение. У нас это будет справочник по растениям.
2. Приложение которое выводит разные сообщения в зависимости от профиля. Сообщения берутся с внешнего файла свойств
Шаг 2. Как бы могли ее решить? Все за и против
И так, есть задача – ищем решение. Начнем по порядку как бы мы могли это сделать.
1. Самый простой с виду вариант. Но только с виду. Мы можем руками указывать наши данные. Если там пару строчек, то это не предоставит много хлопот. Но вот даже при таком раскладе, как часто придется делать такие изменения? И на сколько профессиональный такой подход?
2. Можно сделать какие-то копии файлов для каждого профиля и потом делать подмену. Вроде как хорошо, но все же приходится делать все руками и следить за тем, чтобы случайно не деть где-то важный конфигурационный файл. Который может быть случайно затерт.
3. Давайте разработаем систему, которая в зависимости от параметра будет брать конфигурационный файл для системы! Уже вот автоматизировано. Но, должна ли система, которая занимается расчетом финансовых операций думать о том, в каком режиме запускаться?
Теперь предлагаю посмотреть как мы можем решить наши вопросы более чисто без костылей и велосипедов. Приглашаю всех в след. главу.
Шаг 3. Вводим профили Maven
Теперь как у нас есть таски – давайте их решать. Начнем по порядку. Рассмотрим на примерах как сконфигурировать и некоторые варианты решения данной задачи.
1. У нас есть система с настройками сервера для развертывания.
Для тех кто не знаком с данной технологией, но использует мавен, не нужно вникать что означают сотни строк в конфигурации. Сам принцип будет неизменен и прост. Он может применяться как в EE так и SE.
Предоставляю вашему вниманию наш исходный pom.xm (я опущу некоторые вещи, что нам не будут нужны):
<!--неймспейсы и настройки артифакта--> <name>PlantsReference</name> <properties> <endorsed.dir>${project.build.directory}/endorsed</endorsed.dir> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> <wildfly-hostname>127.0.0.1</wildfly-hostname> <wildfly-port>9990</wildfly-port> <wildfly-username>admin</wildfly-username> <wildfly-password>root</wildfly-password> </properties> <!--настройки зависимостей и плагинов среди которых и тот что нам нужен--> <plugin> <groupId>org.wildfly.plugins</groupId> <artifactId>wildfly-maven-plugin</artifactId> <version>1.0.1.Final</version> <configuration> <hostname>${wildfly-hostname}</hostname> <port>${wildfly-port}</port> <username>${wildfly-username}</username> <password>${wildfly-password}</password> </configuration> <executions> <execution> <phase>package</phase> <goals> <goal>deploy</goal> </goals> </execution> </executions> </plugin>
Как видите, задача слегка упрощенна в том, что наши настройки уже вынесены в property сверху, что даст нам возможность менять данные только в одном месте и не искать по всему помнику. Но это не есть решение. Вводим профили:
<name>PlantsReference</name> <properties> <endorsed.dir>${project.build.directory}/endorsed</endorsed.dir> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> </properties> <profiles> <profile> <id>develop</id> <properties> <wildfly-hostname>127.0.0.1</wildfly-hostname> <wildfly-port>9990</wildfly-port> <wildfly-username>admin</wildfly-username> <wildfly-password>root</wildfly-password> </properties> <activation> <activeByDefault>true</activeByDefault> </activation> </profile> <profile> <id>release</id> <properties> <wildfly-hostname>http://hostname.bank</wildfly-hostname> <wildfly-port>9990</wildfly-port> <wildfly-username>bank_user</wildfly-username> <wildfly-password>bank_password</wildfly-password> </properties> </profile> </profiles>
Как видите, количество properties в начале значительно сократилось и было перенесено в блок profiles. Для профиля develop у нас стоит режим по умолчанию и будет использоваться при сборке проекта. При использовании такой технологии, наши свойства будут вставляться автоматически в зависимости от того какой профиль включен. И кстати, о том, как же узнать что включено, а что нет? Как вовсе выбирать профиль? Мы используем JetBrains intelij IDEA. Здесь это делается одно простой кнопочкой. Если откроете окно сборки проекта, то увидите этот выбор сами.
Согласитесь, намного проще поставить галочку чем делать ручные изменения.
2. Теперь что если наши настройки находятся в файле properties
Не всегда изменения касаются только самой сборки, а и свойств которые влияют на работу самого приложения. Что делать в случае того, если у нас есть conf.properties который должен иметь разные данные для разработки и для релиза? Здесь также помогут профили. У нас есть 2 варианта. Но сначала познакомимся со структурой проекта:
Класс который будет грузить и выводить тип сборки с конфигурационного файла.
public class Example { public static void main(String[] args) throws Exception{ Properties properties = new Properties(); InputStream is = Example.class.getClassLoader().getResourceAsStream("conf.properties"); properties.load(is); System.out.println("Type of app: " + properties.getProperty("type")); } }
Файл conf.properties:
type=develop
И рисунок структуры для наглядности:
Теперь приступим к тому, что мы можем сделать для достижения цели.
1. Настройки в pom.xml
Сейчас наш файлик сборки пуст. Добавляем профили:
<profiles> <profile> <id>develop</id> <properties> <type>develop</type> </properties> <activation> <activeByDefault>true</activeByDefault> </activation> </profile> <profile> <id>release</id> <properties> <type>release</type> </properties> </profile> </profiles> <build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </build>
Здесь мы задаем проперти также как и в предыдущем примере, но вот только теперь в ветке сборки устанавливаем нашу директорию с ресурсами и включаем фильтрацию. И делаем подстановку в наши conf.properties. Сейчас все станет ясно.
type=${type}
Теперь в наш ресурс conf.properties подставиться значения свойства с профиля мавена и будет упаковано в проект. Возьмем полученный архив, распакуем и убедимся в данном.
2. Отдельные настройки для сборок
Но что если у нас этих свойств множество и также множество профилей. Тогда у нас может ужасно сильно вырасти файл с настройками. Чтобы выйти с такой ситуации хочу Вам напомнить, что профили включают в себя не только установку свойств, а и множество другого как: зависимостей, ресурсов, модулей, репозиториев, настроек сборки. Воспользуемся данными преимуществами.
Очистим настройки сборки и добавим туда следующее:
<profiles> <profile> <id>develop</id> <activation> <activeByDefault>true</activeByDefault> </activation> <build> <resources> <resource> <directory>src/main/resources/develop</directory> </resource> </resources> </build> </profile> <profile> <id>release</id> <build> <resources> <resource> <directory>src/main/resources/release</directory> </resource> </resources> </build> </profile> </profiles>
Здесь мы указываем что у нас будет 2 разных ресурса для сборки проекта. Поэтому мы также создадим их:
После чего также будет произведена подмена, но на этот раз конфигурационных файлов при сборке. Таким вот простым и не хитрым образом можно собирать приложение для разных сред с разными настройками.
ПОХОЖИЕ ПУБЛИКАЦИИ
- None Found
1 комментариев к статье "Maven. Создание Profiles"