dependencyManagement и область действия

Немного поздно на вечеринку, но я добавлю свои два цента.

Недавно я столкнулся с очень сложной для отладки проблемой.
У меня есть родительский pom для управления зависимостями в нескольких проектах. Я установил для него все общие для них зависимости и включил groupId, artifactId, version и наиболее распространенные scope.
Я думаю, что мне не нужно включать область видимости в фактическую раздел зависимостей в каждом проекте, если он соответствует наиболее распространенному scope.
Проблема возникает, когда некоторые из этих зависимостей проявляются как транзитивные зависимости. Например, если:

• A зависит от B в области компиляции.
• B зависит от C в области компиляции.
• C установлен в dependencyManagement родительского элемента.

Затем определяется транзитивная зависимость A от C. Я не совсем уверен, имеет ли это смысл или нет, но это определенно сбивает с толку.

В любом случае, избавь себя от хлопот и не включай scope в свой dependencyManagement.

dependencyManagement здесь только для определения версии зависимостей для всех подмодулей проекта, единственная уместная область в этом разделе - import для спецификаций.

Объем должен быть определен в разделе dependencies.

(Для данной зависимости он определяет контекст использования. Он позволяет включать зависимость только тогда, когда она требуется для выполнения. Например, ухо не будет упаковано с зависимостями Java-ee (область provided), поскольку оно найдет их на целевом сервере.)

[изменить]

У первого оператора есть исключение, область видимости provided в разделе dependencyManagement переопределит определенную область в dependencies разделах. см. DependencyManagement, чтобы задать область видимости

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

Если вы определяете область в dependencyManagement, она ограничивает использование этой версии ТОЛЬКО определенной областью, поэтому любые другие области будут выбирать случайную версию зависимости. Я столкнулся с этим вчера, когда мы определили junit 4.12 в dependencyManagement с областью тестирования, но наш общий модуль тестовой среды использовал junit с областью компиляции, поэтому вместо нее была выбрана версия 4.8.2.

Нет никакой выгоды в добавлении одной зависимости к управлению зависимостями для любой области. Все, что у вас есть, - это дублирование. Если вы хотите, чтобы версия настраивалась, добавьте свойство и используйте его в своей зависимости:

<properties>
        <junit.version>4.10</junit.version> 
    ...
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>${junit.version}</version>
    </dependency>
</dependencies>

Однако бывают случаи, когда управление зависимостями проявляется ярко - когда вы используете boms для оркестровки версий для более крупных коллекций артефактов, например, при использовании определенной версии реализации Java EE:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.jboss.bom</groupId>
            <artifactId>jboss-javaee-6.0-with-tools</artifactId>
            <version>${javaee6.with.tools.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
....