Как создать сборку maven с транзитивными зависимостями для разных сценариев развертывания?

У меня возникла проблема согласования создания проекта для использования на сервере приложений и для использования в качестве автономного приложения.

Чтобы дать общий упрощенный контекст, скажем, у меня есть три проекта A, B, C.

Проект A зависит от проекта B, который зависит от проекта C.

Проект C имеет зависимость X, которая помечена как предоставленная, поскольку ожидалось, что она будет доступна в виде библиотеки JEE, скажем, на сервере приложений. то есть jms.jar.

Поэтому, если я выполняю сборку проекта A, я получаю все транзитивные зависимости, за исключением тех, которые помечены как предоставленные, как и ожидалось.

Теперь у меня есть новый сценарий развертывания, в котором Project A необходимо использовать в автономной среде, то есть вне сервера приложений.

Итак, теперь мне нужно, чтобы jms jar был зависимостью компиляции. Означает ли это, что я должен явно добавить зависимость компиляции для X в проекте A? Не нарушает ли это Закон Деметры, то есть не разговаривайте с незнакомцами, в том смысле, что Проект А не должен явно знать о Проекте С, а должен знать только о Проекте Б?

Это простой пример, но на самом деле у меня есть несколько зависимостей, которые были отмечены как предоставленные, но теперь они должны быть зависимы от компиляции или времени выполнения, поэтому они попадают в артефакт, созданный плагином сборки maven.

Это фундаментальная проблема с Maven или я неправильно использую инструменты?

Заранее спасибо за любое руководство.




Ответы (2)


Если вам нужно, чтобы ваша сборка имела вариации для разных сценариев, вам нужно использовать профили и хранить определенные вещи (например, некоторые зависимости) в разных профилях.

http://maven.apache.org/pom.html#Profiles

Различные зависимости для разных профилей сборки в maven

отвечает на аналогичный вопрос, но вы можете поменять местами «релиз» и «отладка» на «Проект A» и «Проект C»

person Ryan    schedule 17.05.2011

Предоставленные зависимости - сложная тема. Прежде всего: предоставленные зависимости не транзитивны в следующем смысле: если ваш проект C имеет предоставленную зависимость от X, то A не получит эту зависимость. Это молча игнорируется. Это согласуется со следующим значением слова «при условии», которое я предлагаю:

Только фактически развернутые артефакты должны помечать зависимости как «предоставленные». Библиотеки или другие jar-файлы, которые не развертываются по отдельности на конкретном сервере, не должны иметь зависимости. Вместо этого они должны объявлять свои зависимости как зависимости компиляции. В вашем примере: проект C должен иметь зависимость компиляции от X. Если проект A знает, что X предоставляется, он устанавливает X как предоставленный в «dependencyManagement». Поскольку проект А должен знать среду, в которой он работает, он должен решить, что предоставляется, а что нет. И «dependenyManagement» — правильное место, чтобы заявить об этом.

Если ваш проект A должен работать как на данном сервере, так и без него, вам, вероятно, потребуется внести множество корректировок, даже изменить тип с ear на jar. Таким образом, вы либо используете для этого профили сборки, которые затем имеют разные записи dependencyManagement, либо вы разделяете A на два проекта, которые зависят от какого-то другого проекта, содержащего общие элементы.

Если какой-то заданный проект C уже имеет предоставленную зависимость от X, и вы не можете ее изменить, это фактически то же самое, что отсутствующая зависимость в C. В какой-то момент это нужно исправить, и это может быть сам проект A.

person J Fabian Meier    schedule 20.03.2017