Maven: специфическая зависимость связки

Question

Представьте, что у вас есть специфическая для среды конструкция, которая возникает в двух путях: дома и офиса. Конкретный артефакт вашей сборки зависит от некоторого общего артефакта, позволяет называть его «ядром». Это просто общая функциональность для сборки для дома и офиса. Домашний артефакт зависит от Core, а артефакт Office зависит от Core. Фактически, Home и Office могут быть одним и тем же артефактом, который просто создается под разными профилями Maven: в случае, если мы называем Maven с -pHomeBundle, он создает артефакт в одну сторону, в случае с -pOfficeBundle - он создает его для офиса, Ядро как зависимость, такая же, как и для дома.

Пока все хорошо.

Теперь возникает вопрос: что мы можем сделать, если основной артефакт, который является общим для комплектов для дома и офиса, имеет зависимости от других артефактов, которые РАЗЛИЧНЫ для комплектов для дома и офиса? То есть Основной артефакт не зависит от пакета, но его зависимости.

Как мы можем обеспечить наше Ядро этими зависимостями?

Как мы можем написать Core POM для этого?

ОБНОВЛЕНИЕ Для решения этой проблемы были предложены два решения: добавьте две связанные с комплектом зависимостей к проекту Core (как показано ниже), а затем добавьте один реальный объект в модуле «Главная/Офис», который принимает Core как зависимость) или добавьте две реальные зависимости от модуля Core, а затем отфильтровать их в модуле, связанном с пакетом Home/Office. Но я не могу получить, с какой зависимостью Core будет строить. Независимо от того, предоставляем ли мы это или нет, он должен строиться с некоторой зависимостью, потому что он поступает в репозиторий. Насколько я понимаю, он просто возьмет первый доступный класс и использует его. Поэтому у меня будет артефакт Core, построенный с использованием одной из зависимостей.

Answer 1

Я бы предпочел, чтобы эти специфические зависимости пакета были добавлены в их соответствующий pom.xml и исключили их в зависимости от основных зависимостей, так что я на 100% уверен, что получаю только эти зависимые библиотеки, добавленные для этого проекта.

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

Надеюсь, это имеет смысл, а также помогает. Любопытно узнать, есть ли у легенд лучший подход.

Answer 2

Re «Дом и офис могут быть даже тот же артефакт»

ли вы имеете в виду здания office и home (снимок или выпуска) с тем же GAV и именем файла банки, но с разными профилями?

Поскольку картинка стоит тысячи слов это, что то, что вы хотите достичь:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
    office-for-core:jar      office:jar  
        \     /    office build 
         \    /
- - - - - - - - - - - (office-) - - -/- - - - - - - - - - - - - - - - 
           core:jar      core build 
- - - - - - - - - - - - (home-) - - - \ - - - - - - - - - - - - - - - - 
         /    \ 
        /    \     home build 
     home-for-core:jar     home:jar 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Answer 3

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

Давайте получим конкретный.

Например: вы зависите от базы данных оракула на работе и базы данных mysql у себя дома. Вы создаете свое программное обеспечение против стандартного интерфейса, скажем, JPA. В вашем домашнем и рабочем контейнерах (допустим, tomcat) должен быть файл свойств, содержащий строку подключения базы данных в банке в папке с библиотекой provided. Затем, когда ваше приложение запустится, оно может получить базу данных среды. Одно приложение, несколько сред.

Другой пример: вы зависите от log4j дома, но в офисе аудирование более строгое, чем это, и вы должны использовать пользовательскую библиотеку. Ваш код построен на стандартном интерфейсе ведения журнала, а в вашем контейнере есть библиотеки log4j в папке provided, когда ваше приложение развернуто дома, оно подберет реализацию log4j, но ваша папка provided на рабочем месте имеет собственное ведение журнала так что, когда ваше приложение запускается там, оно выбирает это вместо этого.

Надеемся, что из приведенных примеров вы можете увидеть, что создаваемому нами программному обеспечению должна быть предоставлена ​​среда с конкретными реалиями среды, которую она ожидает. С современными java, osgi и современными контейнерами это всегда так. Мы всегда можем создавать наше программное обеспечение таким образом. Нам не нужно и никогда не создавать встроенные среды.

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