Maven dependencyManagement и зависимости Tags

1. Обзор

В этом руководстве мы рассмотрим два важных тега Maven — dependencyManagement и dependencies .

Эти функции особенно полезны для многомодульных проектов.

Мы рассмотрим сходства и различия двух тегов, а также рассмотрим некоторые распространенные ошибки, допускаемые разработчиками при их использовании, которые могут вызвать путаницу.

2. Использование

Как правило, мы используем тег dependencyManagement , чтобы избежать повторения тегов версии и области действия , когда мы определяем наши зависимости в теге зависимостей . Таким образом, требуемая зависимость объявляется в центральном файле POM.

2.1. Управление зависимостями

Этот тег состоит из тега зависимостей , который может содержать несколько тегов зависимостей . Каждая зависимость должна иметь как минимум три основных тега: groupId , ArtifactId и version . Давайте посмотрим пример:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
            <version>3.12.0</version>
        </dependency>
    </dependencies>
</dependencyManagement>

Приведенный выше код просто объявляет новый артефакт commons-lang3 , но на самом деле он не добавляет его в список ресурсов зависимостей проекта.

2.2. зависимости

Этот тег содержит список тегов зависимостей . Каждая зависимость должна иметь как минимум два основных тега: groupId и ArtiftId .

Давайте посмотрим на быстрый пример:

<dependencies>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
        <version>3.12.0</version>
    </dependency>
</dependencies>

Теги версии и области действия могут наследоваться неявно, если мы использовали тег dependencyManagement ранее в файле POM :

<dependencies>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
    </dependency>
</dependencies>

3. Сходства

Оба этих тега предназначены для объявления какой-либо сторонней зависимости или зависимости от подмодуля. Они дополняют друг друга.

На самом деле мы обычно определяем тег dependencyManagement один раз, перед тегом зависимостей . Это используется для объявления зависимостей в файле POM. Это объявление является просто объявлением, и на самом деле оно не добавляет зависимости в проект.

Давайте посмотрим на пример добавления зависимости библиотеки JUnit:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.13.2</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Как мы видим в приведенном выше коде, есть тег dependencyManagement , который сам содержит другой тег зависимостей .

Теперь давайте посмотрим на другую сторону кода, которая добавляет фактическую зависимость в проект:

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
    </dependency>
</dependencies>

Итак, текущий тег очень похож на предыдущий. Оба они определяют список зависимостей. Конечно, есть небольшие отличия, о которых мы скоро расскажем.

Одни и те же теги groupId и ArtiftId повторяются в обоих фрагментах кода, и между ними существует значимая корреляция: оба они относятся к одному и тому же артефакту.

Как мы видим, в нашем более позднем теге зависимости нет никакого тега версии . Удивительно, но это корректный синтаксис, и его можно без проблем разобрать и скомпилировать. Причину легко догадаться: будет использоваться версия, объявленная dependencyManagement .

4. Отличия

4.1. Структурная разница

Как мы уже говорили ранее, основное структурное различие между этими двумя тегами заключается в логике наследования. Мы определяем версию в теге dependencyManagement , а затем можем использовать указанную версию, не указывая ее в следующем теге зависимостей .

4.2. Поведенческая разница

dependencyManagement — это просто объявление, и на самом деле оно не добавляет зависимости. Объявленные зависимости в этом разделе должны быть позже использованы тегом зависимостей . Это просто тег зависимостей , который вызывает реальную зависимость. В приведенном выше примере тег dependencyManagement не добавит библиотеку junit ни в какую область. Это просто объявление тега будущих зависимостей .

5. Реальный пример

Почти все проекты с открытым исходным кодом на основе Maven используют этот механизм.

Давайте посмотрим на пример из самого проекта Maven . Мы видим зависимость hamcrest-core , которая существует в проекте Maven. Сначала он объявляется в теге dependencyManagement , а затем импортируется основным тегом зависимостей :

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.hamcrest</groupId>
            <artifactId>hamcrest-core</artifactId>
            <version>2.2</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>org.hamcrest</groupId>
        <artifactId>hamcrest-core</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

6. Распространенные варианты использования

Очень распространенный вариант использования этой функции — многомодульный проект.

Представьте, что у нас есть большой проект, состоящий из разных модулей. Каждый модуль имеет свои собственные зависимости, и каждый разработчик может использовать разные версии используемых зависимостей. Тогда это может привести к мешанине различных версий артефактов, что также может привести к трудным и трудноразрешимым конфликтам.

Простым решением этой проблемы, безусловно, является использование тега dependencyManagement в корневом файле POM (обычно называемом «родительским»), а затем использование зависимостей в дочерних файлах POM (подмодулях) и даже в самом родительском модуле (если применимо). .

Если у нас есть один модуль, есть ли смысл использовать эту функцию или нет? Хотя это очень полезно в многомодульных средах, также может быть эмпирическим правилом следовать ему как лучшей практике даже в одномодульном проекте. Это улучшает читабельность проекта, а также делает его готовым к расширению до многомодульного проекта.

7. Распространенные ошибки

Одной из распространенных ошибок является определение зависимости только в разделе dependencyManagement и не включение ее в тег зависимостей . В этом случае мы столкнемся с ошибками компиляции или выполнения, в зависимости от упомянутой области видимости .

Давайте посмотрим пример:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
            <version>3.12.0</version>
        </dependency>
        ...
    </dependencies>
</dependencyManagement>

Представьте приведенный выше фрагмент кода POM. Затем предположим, что мы собираемся использовать эту библиотеку в исходном файле подмодуля:

import org.apache.commons.lang3.StringUtils;

public class Main {

    public static void main(String[] args) {
        StringUtils.isBlank(" ");
    }
}

Этот код не будет компилироваться из-за отсутствия библиотеки. Компилятор жалуется на ошибку:

[ERROR] Failed to execute goal compile (default-compile) on project sample-module: Compilation failure
[ERROR] ~/sample-module/src/main/java/com/foreach/Main.java:[3,32] package org.apache.commons.lang3 does not exist

Чтобы избежать этой ошибки, достаточно добавить приведенный ниже тег зависимостей в файл POM подмодуля:

<dependencies>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
    </dependency>
</dependencies>

8. Заключение

В этом руководстве мы сравнили теги dependencyManagement и зависимостей Maven. Затем мы рассмотрели их сходства и различия и увидели, как они работают вместе.

Как обычно, код этих примеров доступен на GitHub .