Вам не нужен плагин maven-resources, если у вас простая среда.
В этом примере log4j.properties B
является файл, который вы используете для производства и находится в каталоге src/main/java
и log4j.properties A
это файл, который вы используете для разработки и находится в каталоге /Users/junger/.m2/
.
В вашем pom.xml:
<properties>
<log4j.properties.directory>src/main/java</log4j.properties.directory>
</properties>
<build>
<resources>
<resource>
<directory>${log4j.properties.directory}</directory>
<includes>
<include>log4j.properties</include>
</includes>
</resource>
</resources>
</build>
Теперь в вашем /Users/junger/.m2/settings.xml (создать один, если он не существует):
<profiles>
<profile>
<id>dev</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<log4j.properties.directory>/Users/devuser/.m2/</log4j.properties.directory>
</properties>
</profile>
</profile>
Используя этот метод, каждый разработчик может иметь другой каталог log4j.properties, и вы сохраните свой pom.xml в чистоте.
ли вы использовать Maven-релиз-плагин управления производственной сборки? – yorkw
Нет, я никогда не был сердцем maven-release-плагина раньше. Еще спасибо, я найду, справится ли она с проблемой. – Kedron
Это тихий повторяющийся вопрос, и я хотел бы добавить свои два цента. Создание нескольких сборщиков для разных сред часто не принимается клиентом. Они хотят, чтобы одна конструкция для всех сред устраняла любые проблемы с регрессией с несколькими сборками. Файл log4j должен быть объявлен вне вашего приложения, как любые любые переменные среды. Философия, созданная после развертывания в любом месте, кажется, всегда теряется в профилях сборки maven. – tom