В чем разница между зависимостью типа «pom» с областью видимости «импорт» и без «импорта»?

112

Начиная с Maven 2.0.9 есть возможность включить

<type>pom</type>
<scope>import</scope>

в <dependencyManagement>разделе.

Насколько я понимаю, он будет "заменен" зависимостями, включенными в этот pom, как если бы они были изначально определены здесь.

В чем разница между приведенным выше решением и простой зависимостью от этого pom без importобласти видимости (я видел, что последнее называется «группировкой зависимостей»)? Единственная разница в том, что такие «сгруппированные» зависимости имеют более низкий приоритет при разрешении приоритета зависимостей?

— Grafthez
источник

187

Вы можете импортировать только управляемые зависимости . Это означает, что вы можете импортировать только другие POM в dependencyManagementраздел POM вашего проекта. т.е.

...
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>other.pom.group.id</groupId>
            <artifactId>other-pom-artifact-id</artifactId>
            <version>SNAPSHOT</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>   
    </dependencies>
</dependencyManagement>
...

Затем происходит то, что все зависимости, определенные в dependencyManagementразделе other-pom-artifact-id, включаются в dependencyManagementраздел вашего POM . Затем вы можете ссылаться на эти зависимости в dependencyразделе вашего POM (и всех его дочерних POM) без необходимости включать и versionт. Д.

Однако, если в вашем POM вы просто определяете нормальную зависимость, other-pom-artifact-idтогда все dependenciesиз dependencyраздела other-pom-artifact-idвключены в ваш проект транзитивно, однако зависимости, определенные в dependencyManagementразделе other-pom-artifact-id, не включаются вообще.

Таким образом, в основном используются два разных механизма для импорта / включения двух разных типов зависимостей (управляемые зависимости и обычные зависимости).

На веб-сайте maven есть хорошая страница, которая может объяснить это намного лучше, чем я, Управление зависимостями в Maven, а также содержит конкретную информацию об импорте зависимостей .

— DB5
источник

1

Если pomA in является родительским для pomB, можете ли вы поместить B в управление зависимостями проекта A с областью действия import?

— Janez Kuhar

отличный ответ, чтобы объяснить, как это работает, но почему ?? почему вы не хотите транзитивно включать другие зависимости? также можете сделать и то и другое? импортировать другой-pom-artifact-id, а затем объявить другой-pom-artifact-id как зависимость?

— Цзюньчэнь Лю

В одной статье на DZone говорится о другом:

...   <dependencies>     <dependency>       <groupId>${project.groupId}</groupId>       <artifactId>pomlib-lib</artifactId>       <type>pom</type>       <scope>import</scope>     </dependency>     <dependency>       <groupId>${project.groupId}</groupId>       <artifactId>pomlib-war</artifactId>       <type>war</type>     </dependency>   </dependencies> </project>

DRY и Skinny War

— потому что

1

@JunchenLiu: Допустим, вы используете только пару функций проекта A, поэтому вы можете включить только те переходные зависимости, которые требуются для этой функции. Вы можете решить это, используя <exclude> в <dependency>. Например, посмотрите

— Нитирадж

15

Вы не можете иметь pomтиповой проект simple dependencyв другом проекте. (Ну можно - но ничего полезного не сделает). Могут быть только parent-childотношения. Это по сути managing dependency through inheritance.

importобласть для pomзависимости типа в <dependencyManagement>разделе позволяет получить эквивалент multiple inheritance.

У вас могут быть разные poms- у каждой managingкуча связанных зависимостей. Проекты , которые используют эти могли бы importони , pomsа затем указать зависимости , которые им необходимы , без необходимости беспокоиться о версии. По сути, это bill of materialsконцепция, которая проиллюстрирована в ссылках, указанных в @ DB5.

Это помогает предотвратить parent pomsслишком большие и громоздкие сложные многомодульные проекты.

— Рагурам
источник

8

Ты уверен? Я поставил обычный pom (имеющий свои собственные зависимости) как обычную зависимость в другом проекте (упаковка войны) и получил все зависимости от проекта pom, включенного в WEB-INF / lib целевого проекта. Вот почему я

— задаю

2

Спасибо @Raghuram, совсем забыл упомянуть родительский параметр POM при ответе на вопрос. Что касается проекта типа pom в качестве простой зависимости, это возможно. Как упоминалось в исходном вопросе, его можно использовать для группировки зависимостей

— DB5

1

Рабочая ссылка о групповых зависимостях

— Всеволод Голованов

5

Две концепции, очень похожие на парадигму объектно-ориентированного программирования, помогут ответить на вопрос:

Раздел dependencyManagement только объявляет зависимости и их детали в текущем проекте - цель - управление деталями и их повторное использование в других проектах, либо через наследование ( родительский ) , либо через импорт ( область действия ). Это похоже на объявление типа данных в программе и предоставление его для использования.
Раздел зависимостей определяет фактическое использование зависимостей в проекте, опционально наследует детали (т. Е. Версию и т. Д.) Зависимостей, объявленных в dependencyManagment . Вот почему у вас будут отсутствующие зависимости, если вы поместите их только в dependencyManagment . Это аналогично созданию экземпляра переменной типа данных в программе, где это необходимо.

— фургон
источник

Это хорошо и ясно, но отвечает на другой вопрос, отличный от приведенного выше. :-)

— Rick-777