Maven. Создание Profiles

Сегодня я хотел бы поделиться с Вами информацией по профилям в Мавен. Это действительно очень полезная вещь в арсенале каждого программиста. И сейчас посмотрим почему же.

Шаг 0. Введение

Приходилось ли Вам когда нибудь заводить несколько аккаунтов разных типов, чтобы получить больше возможностей? Заводил ли кто-то из Вас несколько страничек в социальной сети для того, чтобы общаться с одной, а с второй просто послушать музыку или других своих целях?

icons-390

Вместить все это в одном профиле или постоянно переписывать информацию или делать чистку и добавление друзей(что не совсем хорошо скажется на Вашей репутации) не совсем хорошо и удобно. А удобно и быстро — это одно из главных правил программиста. Все должно быть автоматизировано. Сегодня мы поговорим именно о том, как применить профили в 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. Здесь это делается одно простой кнопочкой. Если откроете окно сборки проекта, то увидите этот выбор сами.

1_4432

Согласитесь, намного проще поставить галочку чем делать ручные изменения.

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

И рисунок структуры для наглядности:

2_4432

Теперь приступим к тому, что мы можем сделать для достижения цели.

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 подставиться значения свойства с профиля мавена и будет упаковано в проект. Возьмем полученный архив, распакуем и убедимся в данном.

3_4432

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 разных ресурса для сборки проекта. Поэтому мы также создадим их:

4_4432

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

Урок создан: 12 мая 2014 | Просмотров: 7750 | Автор: Олег Криль | Правила перепечатки


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

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

Ваш e-mail не будет опубликован.

Комментарии:

  • 26 марта 2015 в 22:33

    Андрей

    Код:

    develop

    127.0.0.1
    9990
    admin
    root

    true

    release

    http://hostname.bank
    9990
    bank_user
    bank_password

    Как мы берем данные из POM, т.е. как нам получить данные, например из wildfly-port ???