Как сделать развернутые ресурсы редактируемыми с помощью Maven 2?

Question

У меня есть проект, в котором я создаю JAR, который содержит группу классов с main() плюс набор скриптов, которые устанавливают среду для их вызова. Большинство из них - это длительные процессы, которые много регистрируют (~ 10-20 ГБ).

Это означает, что у меня есть довольно сложный файл log4j.xml, который, находясь в src/main/resources/, попадает в JAR. Когда что-то ломается в производственной системе, я хотел бы изменить ведение журнала на лету для одного запуска.

Итак, мне пришла в голову идея иметь каталог conf/ на производстве и сначала поместить его в classpath. Затем я подумал, что было бы здорово, если бы M2 поместил туда файлы конфигурации (вместо JAR). Но это переписало бы любые ручные изменения во время автоматизированного развертывания, которые я сильно не люблю. Я также не люблю метки времени и тому подобное.

Итак, мои следующие идеи заключались в следующем: M2 должен оставить файлы конфигурации в JAR, но создать копии файлов с именем *.tpl в каталоге conf/. Затем администратор может скопировать шаблон в базовое имя, чтобы переопределить файлы в JAR-файлах. .tpl -Файлы будут перезаписаны, но это не повредит. Администраторы могут полностью контролировать, какая версия журнала активна, и они могут запустить diff, чтобы увидеть, были ли внесены какие-либо важные изменения.

Теперь вопрос: кто-нибудь видел плагин, который автоматизирует этот процесс? То есть, который создает каталог conf/ со всем или выбранным подмножеством всего в src/main/resources/ и который переименовывает файлы?

Answer 1

• Лучшая практика работы с файлами конфигурации в Maven - помещать их в отдельный каталог conf и упаковывать их в двоичную сборку с помощью подключаемого модуля сборки. Размещение файлов конфигурации, таких как log4j.xml, в src / main / resources не имеет смысла, поскольку это не настоящий ресурс приложения, а скорее файл конфигурации.

• Мы справляемся с перезаписью, упаковывая файлы конфигурации с посфиксом .def. Например: myapp.properties упакован в сборку как myapp.properties.def. Когда человек, который использует сборку, распаковывает ее, он не будет перезаписывать свои исходные файлы. После распаковки он просто объединяет их с помощью внешнего инструмента (мы используем meld в Fedora Core).

Answer 2

Похоже, что вы атакуете проблему неправильно. Почему бы просто не запустить приложение с -Dlog4j.configuration=/some/where/my-log4j.properties? Если вы хотите, вы можете добавить флаг командной строки к main(), который напрямую вызывает PropertyConfigurator .

Answer 3

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