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

112

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

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

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

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

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

java maven dependencies pom.xml 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

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

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

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

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