Как создать сборку maven с транзитивными зависимостями для разных сценариев развертывания? - PullRequest
1 голос
/ 17 мая 2011

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

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

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

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

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

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

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

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

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

Заранее спасибо за любые рекомендации.

Ответы [ 2 ]

0 голосов
/ 20 марта 2017

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

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

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

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

0 голосов
/ 17 мая 2011

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...