В чем разница между зависимостями типа "import" и "pom"?

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

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

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

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

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

Ответ 1

Вы можете импортировать только управляемые зависимости. Это означает, что вы можете импортировать только другие 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, включены в ваш раздел POM dependencyManagement. Затем вы можете ссылаться на эти зависимости в разделе dependency вашего POM (и всех его дочерних POM) без необходимости включать version и т.д.

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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