При переходе на Maven из других сред возникает много вопросов, например, как обрабатывать конфигурацию артефакта зависимости.
Что произойдет, например, когда у вашей зависимости есть несколько файлов конфигурации? Стандартный способ Maven — поместить все файлы конфигурации в
src / main / resources . Таким образом, они будут расположены в полученном банке в нужном месте, что позволит вашему приложению функционировать должным образом.
Но что, если вам нужны эти файлы конфигурации, которые могут быть изменены? В случае, если они находятся внутри банки, вы застряли с конфигурацией по умолчанию без возможности редактировать и изменять поведение модуля.
Я предложу здесь способ включить использование такой конфигурации jar.
Допустим, у нас есть модуль, упакованный в Jar, который называется jar-with-conf . Этот модуль содержит единственный класс с именем ConfReader .
Этот класс содержит одну статическую функцию, которая извлекает значение из файла конфигурации по ключу:
public class ConfReader
{
public static String getValue(String key)
{
String val = null;
Configuration config = null;
try
{
config = new PropertiesConfiguration("src/main/config/conf.properties");
}
catch (ConfigurationException e)
{
Logger.error(...)
}
if (config != null)
{
val = config.getString(key);
}
return val;
}
}
Apache commons-configuration используется в этом примере.
Этот модуль также имеет конфигурационный файл с именем conf.properties и находится в src / main / config :
key1=value1
key2=value2
Теперь, скажем, есть приложение, которое зависит от jar-with-conf, называемое app-using-jar-with-conf (простите за имена, которые я назвал — одна из самых сложных задач в информатике, как кто-то сказал). Это самое простое приложение:
public class UsingDepWithConf
{
public static void main( String[] args )
{
System.out.println("value of key1 is " + ConfReader.getValue("key1"));
System.out.println("value of key2 is " + ConfReader.getValue("key2"));
}
}
Конечно, при запуске этого простого метода main getValue () завершится сбоем, поскольку файл конфигурации отсутствует в jar (мы не поместили его в каталог ресурсов).
Чтобы выполнить вышеуказанные требования, мы создадим zip, содержащий каталог config, и развернем его в репозитории Maven. Клиентское приложение получит zip-архив и извлечет его в свою собственную структуру каталогов.
- Создание Zip Для работы
мы будем использовать maven-assembly-plugin . Сначала давайте создадим дескриптор сборки и назовем его zip.xml :<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd">
<id>bin</id>
<baseDirectory>/</baseDirectory>
<formats>
<format>zip</format>
</formats>
<fileSets>
<fileSet>
<directory>${basedir}/src/main/config</directory>
</fileSet>
</fileSets>
</assembly>Говоря простым языком, мы говорим, что хотим создать zip- файл из каталога конфигурации . Далее давайте настроим pom.xml в jar-with-conf для использования этого дескриптора:
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-5</version>
<configuration>
<descriptors>
<descriptor>src/main/assembly/zip.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>Это означает, что мы хотим создать один zip-файл на этапе упаковки в соответствии с файлом сборки zip.xml .
- Развертывание Zip
Конечно, упаковки каталога конфигурации в zip-файл будет недостаточно. Клиентское приложение не может получить к нему доступ. Именно поэтому у нас есть хранилища Maven. Мы развернем zip-файл рядом с артефактом jar модуля. Для этого я буду использовать maven-deploy-plugin . Цель развертывания этого плагина привязана при создании артефакта jar к фазе развертывания в жизненном цикле Maven по умолчанию. Здесь я собираюсь использовать другую цель — файл deploy, который позволяет нам развертывать артефакты, отличные от заданных по умолчанию. Вот фрагмент задачи развертывания в файле pom.xml:<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>deploy-conf-zip</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
</execution>
</executions>
<configuration>
<repositoryId>snapshots</repositoryId>
<file>${project.build.directory}/${project.artifactId}-${project.version}-bin.zip</file>
<url>http://nexus:8081/nexus/content/repositories/snapshots</url>
<groupId>com.my-company.example</groupId>
<artifactId>jar-with-conf-config</artifactId>
<version>${project.version}</version>
<packaging>zip</packaging>
</configuration>
</plugin>В приведенном выше фрагменте целевой файл deploy-file привязан к фазе развертывания , а в разделе конфигурации вся необходимая информация предоставляется для успешного развертывания, например repositoryId (убедитесь, что он настроен в файле settings.xml и что вы иметь разрешения на развертывание в хранилище), URL хранилища и, конечно же, новый идентификатор артефакта — троица groupId , artifactId и version .
- Используя Jar с Zip
Now, давайте настроим приложение так, чтобы оно зависело от артефакта jar-with-conf, а также извлекли папку конфигурации и поместили ее в нужное место. Ниже приведены фрагменты из pom.xml приложения app-using-jar-with-conf : Легкая часть — это зависимость артефакта:<dependency>
<groupId>com.my-company.example</groupId>
<artifactId>jar-with-conf</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>jar</type>
<scope>compile</scope>
</dependency>Далее давайте найдем второй артефакт, который содержит конфигурацию:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<phase>package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.my-company.example</groupId>
<artifactId>jar-with-conf-config</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>zip</type>
<overWrite>false</overWrite>
<outputDirectory>${basedir}</outputDirectory>
</artifactItem>
</artifactItems>
<outputDirectory>${basedir}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>Подробности этого плагина можно найти здесь . Результатом этого будет распакованная папка конфигурации в каталоге src / main в проекте app-using-jar-with-conf . Файл jar-with-conf находится в classpath, и его конфигурация доступна для изменения в клиентском приложении.
Этот вид настройки проекта поощряет модульность в больших системах. Системные архитекторы должны разбить проект на автономные модули с простой и понятной функциональностью и API. Эти модули могут обслуживать любое программное обеспечение, которое нуждается в такой функциональности.
Взято с http://ronenp.wordpress.com/2010/08/12/maven-dependecy-jar-configuration/.