Question

我正在和maven一起工作，虽然他们属于不同的实际项目，但我正在同一家长pom下开发3个班级。这三个类属于不同的pom文件和工件名称，它们（在它们的链式依赖项之外）完全独立为简单起见，我将其称为A，B和C.

A取决于B.
B取决于C.

在某种程度上，A会创建一个新的B实例。

...
B b = new B();
...

B延伸C

...
public class B extends C {
...

这里是pom依赖项：
答：

<dependencies>
    <dependency>
        <groupId>my.group</groupId>
        <artifactId>B</artifactId>
    </dependency>
  </dependencies>
  <dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>my.group</groupId>
            <artifactId>B</artifactId>
            <version>0.0.1</version>
        </dependency>
    </dependencies>
  </dependencyManagement>

B：

<dependencies>
    <dependency>
        <groupId>my.group</groupId>
        <artifactId>C</artifactId>
    </dependency>
  </dependencies>
  <dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>my.group</groupId>
            <artifactId>C</artifactId>
            <version>0.0.1</version>
        </dependency>
    </dependencies>
  </dependencyManagement>

当我在父pom文件上执行maven install时，它正确定义了模块顺序

[INFO] Reactor Build Order:
[INFO]
[INFO] C
[INFO] B
[INFO] A

首先，它正确编译C和B.然后，什么时候编译A：

/path/to/A/A.java[27,28] error: cannot access C

如果您对“27,28”是什么感到好奇，那就是上面引用的“新”这一行。

有趣的是：

如果我首先在B上执行mvn install，然后在A上执行mvn install（我知道原因;）），它可以工作，但由于所请求工作的要求，这不是解决方案。< / LI>
如果我将C添加到A的要求中，它也有效。但它不是一个解决方案，因为C不是A的要求，它是B的要求。如果由于某种原因，A停止使用B，那么无论谁做到这一点也必须记住从其要求中删除C是没有意义的。

我忘了提及：

出于某种原因，在依赖树中：

[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ A ---
[INFO] my.group:A:jar:0.0.1
[INFO] +- my.group:B:jar:0.0.1:provided

C未在需求树中显示为要求。虽然：

[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ B ---
[INFO] my.group:B:jar:0.0.1
[INFO] \- my.group:C:jar:0.0.1:provided

C是B要求树中的要求。

主要的奇怪的事情是：为什么A的需求树中没有C？

Answer 1

这是因为您在A中声明了B的范围为provided。当范围为provided时，maven不包含transitive依赖关系。

引自doc，

此范围仅适用于编译和测试类路径，而且不是传递性的。

maven不包括javac所需的类路径文件

1 个答案: