У меня есть проект с несколькими модулями, где каждый модуль упакован как пакет OSGi, используя Apache Felix maven-bundle-plugin. Весь проект построен с использованием родительского ПОМ, в котором перечислены вышеупомянутые модули. Некоторые модули содержат ресурсы конфигурации (например, файлы .properties), которые не должны быть помещены внутри пакетов для развертывания, а скорее экстернализированы в отдельной папке конфигурации. Моя цель состоит в том, чтобы создать папку распределения (возможно, почтовый файл), который будет выглядеть примерно так:Создание дистрибутива пакетов OSGi с помощью maven-assembly-plugin
my-app-distribution
/bundles
module1-bundle.jar
module2-bundle.jar
etc.
/conf
external1.properties
external2.properties
etc.
где файлы свойств в директории /conf
собираются вручную файлы из /target
папок отдельных модулей. Причина, по которой файлы .properties
необходимо подбирать из целевых папок по сравнению с папками src, заключается в том, что я использую фильтрацию ресурсов Maven, а файлы свойств источника содержат ${..}
заполнители для значений, зависящих от среды. Эти заполнители правильно разрешаются во время процесса сборки - для профилей сборки, а папки target/
содержат фактические значения, зависящие от конкретной среды.
Я делал такие манипуляции с файлами распределения много раз - для дистрибутивов с исполняемыми JAR и т. Д. В этом случае я хотел использовать конфигурацию «modulesSets» дескриптора сборки - легко вытащить все двоичные файлы/банки в одну папку распространения, используя moduleSet/двоичный дескриптор. Также легко исключить некоторые файлы из упаковки в пакет OSGi - в плагин maven-bundle. Единственная проблема, за которую я застрял, - создать папку распространения /conf
и собрать необходимые файлы свойств там. Я попытался использовать «filesSets» внутри дескриптора «modulesSet/sources», чтобы включать только определенные файлы из **/target
каждого модуля, но это, похоже, не работает.
У кого-нибудь есть предложение/совет? Там должен быть простой способ. Или я вообще не должен использовать?
Спасибо,
CV
@PetrKozelka Я не уверен, что извлечение файлов конфигурации специфичны для различных пучков в отдельный модуль является хорошей идеей. Весь смысл OSGi заключается в том, чтобы связки были независимыми и потенциально многоразовыми - как в разработке, так и в дистрибутивах. Имеет смысл только то, что - в исходном коде - реализация функциональности и связанные файлы конфигурации сгруппированы. Для конкретного распространения, хотя мне может понадобиться извлечь некоторые из файлов - если есть требование, чтобы администраторы имели контроль над определенными параметрами. Это может быть разным для другого дистрибутива/приложения. Конфигурация сборки может измениться, но связки/источники останутся неизменными. Кроме того, каждый пучок потенциально может разрабатываться и использоваться отдельно, а не все пакеты всегда должны быть частью одного и того же проекта uber - как вы, кажется, предполагаете. То, что вы предлагаете, похоже, попадает в одну и ту же старую категорию упаковочных корпоративных приложений по типам артефактов (например, «модель», «услуги», «доступ к данным», «конфиг» и т. Д.), А не функциональным доменом/функциями , Такой подход работает нормально в рамках одного приложения/проекта, но не работает на уровне предприятия, где часто возникает необходимость повторно использовать подмножества вертикальных компонентов (разделенных функциональными доменами).
С точки зрения зависимости от макета файла в модулях, я согласен, что такой зависимости не должно быть. Файлы могут быть подобраны по их явному имени или соглашению об именах - по очень специфическим требованиям к дистрибутиву. (Это именно тот случай, с которым я столкнулся.)
Не рекомендуется брать файлы с субмодулей напрямую, так как они подвержены ошибкам - особенно при изменении формата файла и т. Д. Обычно лучше присоединить конфигурацию в качестве вторичного артефакта вывода с определенным типом и классификатор, а затем использовать его как зависимость. В вашем случае, возможно, имеет смысл иметь один модуль для обработки всех конфигураций или поместить его в дистрибутивный модуль. –