Разработайте экологически чистый процесс сборки Maven

1. О переменных среды
2. Экологически зависимое управление зависимостями в Maven
3. Настройка проекта
4. Настройка демонстрации и исходный код
5. Пример приложения: Mule ESB
6. Рисунок 1. Схема предлагаемого решения для сборки Maven (нажмите, чтобы увеличить)
7. Листинг 1. Mule-приложение ESB pom.xml

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

Java-приложению, размещенному на сервере приложений, обычно требуется доступ к набору пар ключ-значение, которые предоставляют переменные среды выполнения, например URL-адрес соединения JDBC. В этой статье я продемонстрирую другой подход к разработке приложений, учитывающих среду, сделав переменные среды частью процесса сборки Maven.

Разработка процесса сборки, учитывающего среду, включает в себя два плагина Maven и два небольших проекта для вашего кода. Указание среды сборки в качестве аргумента JVM на этапе сборки Maven будет динамически устанавливать файлы свойств, чтобы отражать правильные значения для данной среды. Все файлы свойств будут помещены в каталог, доступный для пути к классам, а не объединены в JAR-файлы.

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

О переменных среды

Переменная времени выполнения - это любая переменная, которая может измениться в среде, в которой развернуто программное обеспечение. Например, большинство приложений Java используют реляционную базу данных для сохранения состояния, а URL-адрес соединения JDBC базы данных и соответствующие учетные данные пользователя будут различаться в разных средах. URL-адрес и учетные данные JDBC-соединения являются переменными времени выполнения.

Как разработчик программного обеспечения, вы не можете полностью избежать зависимостей от времени выполнения. Но у вас есть варианты того, как ваше программное обеспечение будет получать информацию, необходимую для взаимодействия с этими зависимыми системами в различных средах. Распространенным подходом является использование операционной системы, на которой размещается программное обеспечение, для обнаружения его зависимостей. Например, в Windows вы можете использовать реестр для захвата переменных среды выполнения при установке приложения. Другой вариант заключался бы в инкапсуляции переменных среды в виде пар ключ-значение в файлах свойств, связанных с вашим приложением. Эти файлы свойств будут затем доступны для разработчиков и администраторов.

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

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

Экологически зависимое управление зависимостями в Maven

Вы можете быть знакомы с использованием Maven строить профили загружать переменные в процесс сборки для разных сред. Переменные, определенные в профиле сборки, доступны в каждом файле pom.xml, предназначенном для использования при создании развертываемых артефактов. Профили сборки эффективны, но для их использования необходимо вручную развернуть файл settings.xml в каталоге $ USERHOME \ .m2 на машине сборки или в каталоге $ M2_HOME / conf / settings.xml. Это делает полученное приложение менее переносимым, чем хотелось бы. Профили сборки также не легко справляются с развертыванием различных наборов файлов свойств для каждого приложения и среды.

В этой статье я продемонстрирую альтернативу использованию профилей сборки Maven для разработки сборки, учитывающей среду. Работа в среде сборки с учетом среды означает, что когда программное обеспечение компилируется и / или встраивается в развертываемый пакет, все файлы свойств будут существовать как часть проекта и будут правильно настроены для целевой среды.

Хотя это может быть не так важно для разработчиков, ориентированных на работу в среде разработки, это становится важным на других этапах жизненного цикла разработки программного обеспечения (SDLC). Например, во время цикла обслуживания программного обеспечения группа управления конфигурацией обычно переупаковывает программное обеспечение для тестовой среды перед выпуском в производственную среду. Тестовая среда обычно отражает производственную среду, поэтому она должна быть подключена ко всем внешним системам, необходимым для правильного размещения и тестирования всех функций, предоставляемых программным обеспечением. Настройка файлов свойств программного обеспечения для использования во время развертывания, даже во время тестирования, должна быть гладким и простым процессом и не должна требовать помощи команды разработчиков.

Для проектов, уже использующих Maven, имеет смысл усовершенствовать существующую систему сборки Maven, а не вводить другую систему или набор инструментов управления зависимостями.

Настройка проекта

Чтобы следовать примерам, вам потребуется следующая настройка в вашей среде разработки:

1. App-Config : проект Maven, который содержит все файлы свойств в виде шаблонов для трех сред: разработки, тестирования и производства. App-Config также содержит главный файл свойств для каждой среды, который содержит пары ключ-значение свойства для всех переменных приложения, используемых во время выполнения.
2. Parent-Pom : проект Maven, содержащий родительский POM для наследования другими проектами Maven.
3. Maven-зависимость-плагин а также Maven-ресурсы-плагин , Они будут использоваться POM проекта Parent-Pom и отдельными POM проекта для копирования и фильтрации шаблонов файлов свойств.

Настройка демонстрации и исходный код

Проекты Maven, использованные в этой статье, создают приложение Mule ESB 3.2 с использованием плагина Eclipse m2eclipse Maven и плагина Eclipse Maven Mule. Проекты Maven были построены в Eclipse Indigo. Пока тебе не нужно скачать проекты следовать примеру, это может быть полезно. Увидеть Ресурсы подробнее о настройке среды разработки.

Пример приложения: Mule ESB

Приложение Mule ESB состоит из ZIP-файла, который содержит классы и JAR-файлы, ресурсы и файл mule-config.xml. Это содержимое помещается в определенные области файла ZIP, так же, как файл WAR определяет конкретную структуру каталогов. Плагин Maven Mule создает артефакт ZIP на этапе упаковки, а также копирует файлы в правильные каталоги внутри ZIP. Плагин Mule также включает зависимые файлы JAR в ZIP.

Чтобы продемонстрировать процесс сборки с учетом среды, мы создадим приложение Mule ESB, которое содержит два других приложения (связанных как JAR), каждое из которых содержит свои собственные файлы свойств. Один из JAR-файлов будет содержать код соединения с базой данных JDBC MS SQL Server, который считывает информацию о соединении с базой данных из файла свойств с именем database.properties. Другой JAR будет содержать клиент веб-службы SOAP, который использует файл свойств для загрузки информации, необходимой для подключения к серверу, на котором размещены веб-службы.

Следует отметить, что выбор использования Mule ESB был сделан только потому, что полученный в результате артефакт сборки Maven представляет собой ZIP, а структура папок ZIP идеально подходит для этого примера. Проект, который создает артефакт WAR, был бы таким же действительным. Также обратите внимание, что обычно вы позволяете вашему ESB обрабатывать установление и управление подключениями к базе данных и веб-сервисам, но опять же, Mule ESB был выбран для создаваемого артефакта.

Полное решение в этом примере состоит из трех приложений, каждое из которых настроено как проект Maven:

1. Проект Mule ESB Maven
2. Проект Database Maven
3. Проект Maven клиента веб-службы SOAP

Для целей этой статьи не так важно, почему или как приложение Mule ESB использует два других проекта, поэтому я не буду тратить время на детали их функциональности. Вместо этого мы сосредоточимся на правильной настройке файлов свойств для всех трех проектов. Когда проект Mule ESB встроен в его ZIP-артефакт, все файлы свойств, связанные внутри ZIP, должны содержать свойства, специфичные для данной среды развертывания. Поскольку два JAR-файла приложения Mule подключаются к внешним системам и используют файлы свойств для получения информации об этих внешних системах, мы можем предположить, что эта информация может изменяться в зависимости от среды.

На рисунке 1 представлен обзор расширенной системы сборки Maven.

Рисунок 1. Схема предлагаемого решения для сборки Maven (нажмите, чтобы увеличить)

Распаковка примеров приложений

Давайте посмотрим на файлы pom для каждого из наших приложений, начиная с приложения Mule в листинге 1.

Листинг 1. Mule-приложение ESB pom.xml

<? xml version = "1.0" encoding = "UTF-8"?> <project xmlns = "http://maven.apache.org/POM/4.0.0" xmlns: xsi = "http: //www.w3 .org / 2001 / XMLSchema-instance "xsi: schemaLocation =" http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd "> <modelVersion> 4.0 .0 </ modelVersion> <groupId> com.techflow.bcs3.ldp.mule-esb </ groupId> <artifactId> mule-app </ artifactId> <packaging> mule </ packaging> <name> Mule Application </ name > <description> Приложение Mule, которое подключается как к базе данных, так и к веб-службе. </ description> <version> $ {app.version} </ version> <properties> <app.version> 1.0-SNAPSHOT </app.version> <mule.version> 3.2.0 </mule.version> <database.version> 1.0-SNAPSHOT </database.version> <web-service-client.version> 1.0-SNAPSHOT </web-service-client.version> </ properties> <build> <pluginManagement> <plugins> <plugin> <groupId> org.apache.maven.plugins </ groupId> <artifactId> maven-install-plugin </ artifactId> <версия> 2.3.1 </ версия> </ plugin> <! - Конфигурация этого плагина используется для хранения Eclipse m2e только настройки Это не имеет никакого влияния на саму сборку Maven. -> <plugin> <groupId> org.eclipse.m2e </ groupId> <artifactId> отображение жизненного цикла </ artifactId> <версия> 1.0.0 </ version> <конфигурация> <! - содержимое, не отображаемое в этом статья для краткости. -> </ configuration> </ plugin> </ plugins> </ pluginManagement> <plugins> <plugin> <groupId> org.mule.tools </ groupId> <artifactId> maven-mule-plugin </ artifactId> < версия> 1.7 </ version> <extensions> true </ extensions> </ plugin> <plugin> <groupId> org.apache.maven.plugins </ groupId> <artifactId> maven-compiler-plugin </ artifactId> <версия > 2.3.2 </ version> </ plugin> </ plugins> </ build>! - Зависимости Mule -> <зависимость> <зависимость> <groupId> xalan </ groupId> <artifactId> xalan </ artifactId> <версия> 2.7.1 </ версия> <область действия> </ scope> </ зависимость> <зависимость> <groupId> xerces </ groupId> <artifactId> xercesImpl </ artifactId> <версия> 2.9.1 </ version > <scope> предоставлено </ scope> </ dependency> <dependency> <groupId> xml-apis </ groupId> <artifactId> xml-apis </ artifactId> <версия> 1.3.04 </ version> <scope> <scope> </ scope> </ dependency> <dependency> <groupId> com.foo </ groupId> <artifactId> database </ artifactId> <версия> $ {database.version} </ version> <scope> compile </ scope> </ зависимость> <зависимость> <groupId> co m.foo </ groupId> <artifactId> клиент веб-службы </ artifactId> <версия> $ {web-service-client.version} </ version> <scope> compile </ scope> </ dependency> </ зависимости> </ project>

На рисунке 2 показана структура каталогов проекта Maven приложения Mule ESB в Eclipse Indigo.

Рисунок 2. Структура каталога ESB Mule

Похожие

Комментарии