Транзитивные зависимости, предоставляемые предоставленной областью действия и областью компиляции, вычисляются как область компиляции - PullRequest
Новая
       16

Транзитивные зависимости, предоставляемые предоставленной областью действия и областью компиляции, вычисляются как область компиляции

1 голос
/ 13 марта 2019

Мы сталкиваемся с проблемой, когда один и тот же artifact-X транзитивно переносится dependency-1 с предоставленной областью , а другой dependency-2 с стандартной (компилируемой) областью. Это artifact-X будет вычислено как compile scope, в то время как мы ожидаем, что оно будет явно предоставлено dependency-1.

Например, dependency-1 pom содержит: 

    <dependencies>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
            <version>3.7</version>
        </dependency>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-collections4</artifactId>
            <version>4.1</version>
        </dependency>
    </dependencies>

dependency-2 Пом содержит: 

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

Сборка проекта пом содержит: 

    <dependencies>
        <!-- do not include dependencies already provided by module-1 at runtime -->
        <dependency>
            <groupId>com.company</groupId>
            <artifactId>module-1</artifactId>
            <version>1.0</version>
            <scope>provided</scope>
        </dependency>

        <!-- get dependencies required by module-2 runtime -->
        <dependency>
            <groupId>com.company</groupId>
            <artifactId>module-2</artifactId>
            <version>1.0</version>
        </dependency>
    </dependencies>

Но mvn dependency:tree в сборочном проекте выдаст: 

[INFO] --- maven-dependency-plugin:3.1.0:tree (show-app-dependencies) @ module-3 ---
[INFO] com.company:module-3:pom:1.0
[INFO] +- com.company:module-1:jar:1.0:provided
[INFO] |  +- org.apache.commons:commons-lang3:jar:3.7:compile
[INFO] |  \- org.apache.commons:commons-collections4:jar:4.1:provided
[INFO] \- com.company:module-2:jar:1.0:compile

И мы можем видеть, что артефакт commons-lang3:jar:3.7, полученный из зависимости-1, теперь находится в compile scope. Обратите внимание, что здесь мы не используем <dependencyManagement>.

Это очень запутанно и приводит к дублированию библиотек в пути к классам времени выполнения, когда dependency-1 эффективно предоставляется в пути к классам dependency-2 времени выполнения (например, сервером приложений).

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

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

Кажется, это ошибка, что maven-3.6 не обрабатывает, что является позором!

Однако, поскольку наша цель состоит в том, чтобы просто упаковать ТОЛЬКО библиотеки, определенные как время компиляции / выполнения (и игнорировать все предоставленные библиотеки и их транзитивные элементы), как этого добиться с помощью управления зависимостями или, если невозможно, с помощью maven-assembly- плагин ??

...