Строительство для разных сред

Создание одного и того же артефакта для разных сред всегда раздражало. У вас есть несколько сред, например тестовые и производственные серверы или, возможно, набор серверов, на которых выполняется одно и то же приложение с разными конфигурациями. В этом руководстве я объясню, как вы можете использовать профили для сборки и упаковки артефактов, настроенных для определенных сред. См. Введение в создание профилей для более подробного объяснения концепции профиля.

Примечание:

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

В этом примере предполагается использование стандартного макета каталога.

pom.xml
src/
  main/
    java/
    resources/
  test/
    java/

В src/main/resources есть три файла:

• environment.properties - Это конфигурация по умолчанию, которая по умолчанию будет упакована в артефакт.
• environment.test.properties - Это вариант для тестовой среды.
• environment.prod.properties - Это в основном то же самое, что и тестовый вариант, и будет использоваться в производственной среде.

В дескрипторе проекта вам необходимо настроить различные профили. Здесь показан только тестовый профиль.

<profiles>
<profile>
    <id>test</id>
    <build>
    <plugins>
        <plugin>
        <artifactId>maven-antrun-plugin</artifactId>
        <executions>
            <execution>
            <phase>test</phase>
            <goals>
                <goal>run</goal>
            </goals>
            <configuration>
                <tasks>
                <delete file="${project.build.outputDirectory}/environment.properties"/>
                <copy file="src/main/resources/environment.test.properties"
                        tofile="${project.build.outputDirectory}/environment.properties"/>
                </tasks>
            </configuration>
            </execution>
        </executions>
        </plugin>
        <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
            <skip>true</skip>
        </configuration>
        </plugin>
        <plugin>
        <artifactId>maven-jar-plugin</artifactId>
        <executions>
            <execution>
            <phase>package</phase>
            <goals>
                <goal>jar</goal>
            </goals>
            <configuration>
                <classifier>test</classifier>
            </configuration>
            </execution>
        </executions>
        </plugin>
    </plugins>
    </build>
</profile>

.. Other profiles go here ..

</profiles>

В этом фрагменте настраиваются три вещи:

• Он настраивает плагин antrun для выполнения цели запуска на этапе тестирования, когда он копирует файл environment.test.properties в environment.properties.
• Он настроит тестовый плагин на пропуск всех тестов при создании тестовых и производственных артефактов. Это полезно, поскольку вы, вероятно, не хотите запускать тесты в производственной системе.
• Он настраивает плагин JAR для создания «прикрепленного» JAR с «тестовым» классификатором.

Чтобы активировать этот профиль, выполните mvn -Ptest install, и Maven выполнит шаги в профиле в дополнение к обычным шагам. Из этой сборки вы получите два артефакта: «foo-1.0.jar» и «foo-1.0-test.jar». Эти два jar будут идентичными.

Предостережения

• В настоящее время Maven не позволяет сборке проекта создавать только прикрепленные артефакты. (т.е. он также должен создать «главный» артефакт). Это приводит к тому, что два равных JAR упаковываются и устанавливаются. Плагин JAR, вероятно, также должен получить улучшенную поддержку для этого варианта использования, чтобы два разных каталога вывода были использованы в качестве основы для создания JAR.
• Использование задачи удаления может показаться немного странным, но оно необходимо, чтобы убедиться, что задача копирования действительно скопирует файл. Задача копирования будет проверять временные метки исходного и целевого файлов, только при копировании файлов она не будет знать, что фактический исходный файл может отличаться от последнего выполнения.
• После сборки тестовая конфигурация будет находиться в target / classes и не будет переопределена, потому что плагин ресурсов использует ту же проверку метки времени, поэтому вы всегда должны выполнять чистку после выполнения Maven с профилем.
• По причинам, указанным выше, крайне важно, чтобы вы создавали артефакт только для одной среды за один раз и выполняли команду «mvn clean» всякий раз, когда вы меняете переключатели профиля. В противном случае вы можете получить артефакты со смешанным набором файлов конфигурации.