В чем разница между зависимостями типа "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. Это аналогично созданию экземпляра переменной типа данных в программе, где это необходимо.