Удивительно, что в 2019 году в Maven до сих пор нет подходящих плагинов для управления средами. Единственный, кто пытается решить проблемы управления окружающей средой, — это multienv-maven-plugin
( https://github.com/khmarbaise/multienv-maven-plugin ) Хмарбайз. В этой статье мы обсудим детали использования environment-maven-plugin , оценим, чего не хватает multienv-maven-plugin , и рассмотрим возможные решения этой проблемы. Давайте углубимся в это!
Не допускает исключения сред
Почти для всех проектов, над которыми я работал, у них есть файлы ресурсов как для различных сред, так и для запуска кода на компьютере разработчика, но указывающие на различные среды. Например: dev
, dev_local
, ci
, ci_local
, qa
, qa_local
и т.д. — эти файлы QA ресурсы используются для запуска приложения в среде QA. qa_local
файлы ресурсов используются для запуска приложения на компьютере разработчика, указывая на среду QA. Когда сборка выпуска запускается, файлы войны для dev_local
, ci_local
и qa_local
не должны быть сгенерированы. В противном случае это замедляет сборку и загромождает бамбуковые страницы сборки, что может вызвать путаницу у стороны, выполняющей фактическое развертывание.
multienv-maven-plugin основан на философии, согласно которой каждый каталог в src / main / средах представляет собой среду, а все каталоги в src / main / средах являются средами. Кроме того, файл war создается для каждой среды. Эта философия обеспечивает простоту, но делает это за счет надлежащей функциональности.
environment-maven-plugin позволяет исключить среды, для которых генерация военных файлов нежелательна. Это можно сделать с помощью excludeEnvironments
тега в конфигурации плагина.
Пример конфигурации
<plugin>
<groupId>net.sf.environments-maven-plugin</groupId>
<artifactId>environments-maven-plugin</artifactId>
<version>1.1.0-SNAPSHOT</version>
<configuration>
<excludeEnvironments>dev01, qa01 ,qa02,</excludeEnvironments>
<parallel>true</parallel>
</configuration>
<executions>
<execution>
<goals>
<goal>configuration</goal>
</goals>
</execution>
</executions>
</plugin>
Не разрешает манифест настройки
Когда файлы war генерируются для разных сред, могут быть случаи, когда необходимо добавить записи манифеста для конкретной среды. multienv-maven-plugin не предоставляет этого. Это можно легко сделать с помощью environment-maven-plugin, используя environmentArchiveConfiguration
тег в конфигурации плагина.
Вы можете иметь одну конфигурацию для всех сред или конфигурацию для каждой отдельной среды, как показано ниже.
Для простоты среда уже добавлена в каждый файл войны. Запись манифеста выглядит следующим образом .
Окружающая среда: ci_local
Пример конфигурации
<project>
...
<build>
<plugins>
<plugin>
<groupId>net.sf.environments-maven-plugin</groupId>
<artifactId>environments-maven-plugin</artifactId>
<version>1.1.0-SNAPSHOT</version>
<configuration>
<excludeEnvironments>dev01, qa01</excludeEnvironments>
<parallel>true</parallel>
<archives>
<environmentArchiveConfiguration>
<environment>dev02</environment>
<archive>
<manifestEntries>
<mode>development</mode>
<key>value</key>
</manifestEntries>
</archive>
</environmentArchiveConfiguration>
<environmentArchiveConfiguration>
<environment>prod01, prod02</environment>
<archive>
<manifestEntries>
<mode>development1</mode>
<key>value1</key>
</manifestEntries>
</archive>
</environmentArchiveConfiguration>
</archives>
</configuration>
<executions>
<execution>
<goals>
<goal>configuration</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
Не имеет специфичной для окружающей среды фильтрации
сред-Maven-плагин вводит и теги. тег принимает путь к каталогу внутри src / main / environmentnments . Общий каталог содержит шаблоны, которые являются общими для всех сред. Эти шаблоны могут иметь переменные, которые заключены в ( ). commonDir
filters
commonDir
@
@variable@
filters
Тег может иметь несколько filter
меток. Каждый filter
тег принимает имя файла.
Когда войны построены, плагин делает следующее.
- Извлекает файлы шаблонов из общего каталога.
- Извлекает файлы с именами, объявленными в
filter
тегах, из каталога среды. Например, если в данный момент создается dev war, плагин пытается найти файлы поfilter
тегам в каталоге src / main / сред / dev . - Объединяет все пары ключ-значение из всех файлов в
filter
тегах вHashMap
. - Использует эти пары ключ-значение из
HashMap
переменных для замены в шаблоне. - Упакует файлы из предыдущего шага в файл dev war.
- Также упаковывает все файлы из каталога src / main / сред / $ {env} .
Пример конфигурации
<plugin>
<groupId>net.sf.environments-maven-plugin</groupId>
<artifactId>environments-maven-plugin</artifactId>
<version>1.3.0-SNAPSHOT</version>
<configuration>
<commonDir>common</commonDir>
<filters>
<filter>ec.properties</filter>
</filters>
</configuration>
<executions>
<execution>
<goals>
<goal>environment</goal>
</goals>
</execution>
</executions>
</plugin>
Изображение ниже иллюстрирует структуру файла / каталога.
Чтобы фильтрация работала, оба commonDir
и filters
теги должны быть объявлены.
Не предоставляет средства для размещения файлов ресурсов в определенном каталоге внутри файла War
Файлы ресурсов обычно находятся в каталоге WEB-INF / classes внутри файла war. Чтобы добиться этого в multimaven-maven-plugin , нужно создать каталог WEB-INF / classes в каждой из сред внутри src / main / сред, а затем поместить в них файлы ресурсов. Как показано ниже, это избыточно и безобразно.
- ЦСИ
- главный
- окружающая среда
- DEV
- WEB-INF
- классы
- файлы
- классы
- WEB-INF
- dev_local
- WEB-INF
- классы
- файлы
- классы
- WEB-INF
- CI
- WEB-INF
- классы
- файлы
- классы
- WEB-INF
- ci_local
- WEB-INF
- классы
- файлы
- классы
- WEB-INF
- DEV
- окружающая среда
- главный
Чтобы решить эту проблему, Environment-Maven-плагин представляет новый тег под названием . Если этот тег объявлен с путем к каталогу для значения, файлы ресурсов, упакованные в war, помещаются в каталог. Так. это выглядит так targetPath
- app_dev.jar
- WEB-INF
- classes
- files
- classes
- WEB-INF
- app_dev_local.jar
- WEB-INF
- classes
- files
- classes
- WEB-INF
- app_ci.jar
- WEB-INF
- classes
- files
- classes
- WEB-INF
- app_ci_local.jar
- WEB-INF
- classes
- files
- classes
- WEB-INF
So the directory structure looks like this in that case.
- src
- main
- environments
- dev
- files
- dev_local
- files
- ci
- files
- ci_local
- files
- dev
- environments
- main
Example Configuration
<plugin>
<groupId>net.sf.environments-maven-plugin</groupId>
<artifactId>environments-maven-plugin</artifactId>
<version>1.1.0-SNAPSHOT</version>
<configuration>
<targetPath>WEB-INF/classes</targetPath>
</configuration>
<executions>
<execution>
<goals>
<goal>environment</goal>
</goals>
</execution>
</executions>
</plugin>
Doesn’t Allow Building a Single Environment
multienv-maven-plugin doesn’t provide the facility to build a single environment. The result is that one will have to maintain an entirely separate set-up just for individual environments. environments-maven-plugin solves this problem with a command line option -Dem.env. The value of the option is the directory name of the environment of interest in src/main/environment.
mvn clean install -Dem.env=dev_local
Conclusion
environments-maven-plugin is a fork of mutlienv-maven-plugin. I did submit pull requests to multienv-maven-plugin, but either I said something the kind gentleman didn’t want to hear or he heard something I didn’t say. The net result is the pull requests didn’t get approved. So I had to fork it.
There are issues with 1.0, 1.1, and 1.2. Please use the latest version: 1.3.
Project Page: https://sourceforge.net/projects/environments-maven-plugin/
Source Code: https://sourceforge.net/p/environments-maven-plugin/code/ci/master/tree/
Overview page: https://environments-maven-plugin.sourceforge.io/index.html
Lastly, the plugin is in Maven Central.
If you feel like asking why not GitHub, the answer is pretty simple— that bandwagon is already too crowded.