在具有模块间测试依赖项的 Maven 版本中正确实现 Java 模块

我有一个使用Maven和Java的多模块项目。我现在正试图迁移到Java 9/10/11并实现模块(如JSR 376:Java Platform Module System,JPMS)。由于该项目已经由Maven模块组成,并且依赖项是直接的,因此为项目创建模块描述符非常简单。

现在,每个 Maven 模块在文件夹中都有自己的模块描述符 ()。测试类没有模块描述符。module-info.javasrc/main/java

但是,我偶然发现了一个我无法解决的问题,并且没有找到有关如何解决的任何描述:

如何与 Maven 和 Java 模块建立模块间测试依赖关系?

在我的情况下,我有一个“通用”Maven模块,其中包含一些接口和/或抽象类(但没有具体的实现)。在同一个 Maven 模块中,我有抽象测试来确保这些接口/抽象类实现的正确行为。然后,有一个或多个子模块,其中包含接口/抽象类的实现和扩展抽象测试的测试。

但是,当尝试执行 Maven 构建的阶段时,子模块将失败,并显示:test

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:testCompile (default-testCompile) on project my-impl-module: Compilation failure: Compilation failure:
[ERROR] C:\projects\com.example\my-module-test\my-impl-module\src\test\java\com\example\impl\FooImplTest.java:[4,25] error: cannot find symbol
[ERROR]   symbol:   class FooAbstractTest
[ERROR]   location: package com.example.common

我怀疑发生这种情况是因为测试不是模块的一部分。即使 Maven 做了一些“魔术”来让测试在模块范围内执行,它也不适用于我所依赖的模块中的测试(出于某种原因)。如何解决此问题?

项目的结构如下所示(此处提供完整的演示项目文件):

├───my-common-module
│   ├───pom.xml
│   └───src
│       ├───main
│       │   └───java
│       │       ├───com
│       │       │   └───example
│       │       │       └───common
│       │       │           ├───AbstractFoo.java (abstract, implements Foo)
│       │       │           └───Foo.java (interface)
│       │       └───module-info.java (my.common.module: exports com.example.common)
│       └───test
│           └───java
│               └───com
│                   └───example
│                       └───common
│                           └───FooAbstractTest.java (abstract class, tests Foo)
├───my-impl-module
│   ├───pom.xml
│   └───src
│       ├───main
│       │   └───java
│       │       ├───com
│       │       │   └───example
│       │       │       └───impl
│       │       │           └───FooImpl.java (extends AbstractFoo)
│       │       └───module-info.java (my.impl.module: requires my.common.module)
│       └───test
│           └───java
│               └───com
│                   └───example
│                       └───impl
│                           └───FooImplTest.java (extends FooAbstractTest)
└───pom.xml

中的依赖关系如下:my-impl-module/pom.xml

<dependencies>
    <dependency>
        <groupId>com.example</groupId>
        <artifactId>my-common-module</artifactId>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>com.example</groupId>
        <artifactId>my-common-module</artifactId>
        <classifier>tests</classifier> <!-- tried type:test-jar instead, same error -->
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

注意:以上只是我为演示问题而创建的项目。真正的项目要复杂得多,在这里可以找到(主分支还没有模块化),但原理是一样的。

PS:我不认为代码本身有什么问题,因为所有内容都使用正常的类路径(即在IntelliJ中,或没有Java模块描述符的Maven)进行编译和运行。Java 模块和模块路径引入了此问题。


答案 1

根据您的演示项目,我能够复制您的错误。也就是说,以下是我在第一次尝试失败后所做的修改更改,以便能够构建项目:

  1. 我将版本3.8.0添加到所有模块中。您需要 3.7 或更高版本才能使用 Maven 编译模块 — 至少这是 NetBeans 显示的警告。由于没有危害,我将插件添加到公共模块和实现模块的POM文件中:maven-compiler-plugin

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.0</version>
        <executions>
            <execution>
                <goals>
                    <goal>compile</goal>
                </goals>
                <id>compile</id>
            </execution>
        </executions>
    </plugin> 
    
  2. 我将测试类导出到它们自己的文件中,以便您的实现模块或任何人都可以使用它们。为此,您需要将以下内容添加到文件中:jarmy-common-module/pom.xml

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>3.1.0</version>
        <executions>
            <execution>
                <id>test-jar</id>
                <phase>package</phase>
                <goals>
                    <goal>test-jar</goal>
                </goals>
            </execution>
        </executions>
    </plugin>
    

    这会将测试类导出到文件中 - 即请注意,没有必要为常规文件添加执行,如本文所述。但是,这将引入错误,我将在下面解决。my-common-module-tests.jarmy-common-module-1.0-SNAPSHOT-tests.jarjar

  3. 将测试包重命名为 ,以便在编译实现测试类时加载测试类。这纠正了当我们导出与模块中具有相同包名称的测试类时引入的类加载问题,其中第一个(在本例中为模块)被加载,第二个测试 jar 文件被忽略。有趣的是,根据观察结果,我得出结论,模块路径的优先级高于类路径,因为Maven编译参数显示类路径中首先指定的。运行 ,我们看到编译参数:my-common-modulecom.example.common.testjarjartests.jarmvn clean validate test -X

    -d /home/testenv/NetBeansProjects/MavenProject/Implementation/target/test-classes -classpath /home/testenv/NetBeansProjects/MavenProject/Implementation/target/test-classes:/home/testenv/.m2/repository/com/example/Declaration/1.0-SNAPSHOT/Declaration-1.0-SNAPSHOT-tests.jar:/home/testenv/.m2/repository/junit/junit/4.12/junit-4.12.jar:/home/testenv/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar: --module-path /home/testenv/NetBeansProjects/MavenProject/Implementation/target/classes:/home/testenv/.m2/repository/com/example/Declaration/1.0-SNAPSHOT/Declaration-1.0-SNAPSHOT.jar: -sourcepath /home/testenv/NetBeansProjects/MavenProject/Implementation/src/test/java:/home/testenv/NetBeansProjects/MavenProject/Implementation/target/generated-test-sources/test-annotations: -s /home/testenv/NetBeansProjects/MavenProject/Implementation/target/generated-test-sources/test-annotations -g -nowarn -target 11 -source 11 -encoding UTF-8 --patch-module example.implementation=/home/testenv/NetBeansProjects/MavenProject/Implementation/target/classes:/home/testenv/NetBeansProjects/MavenProject/Implementation/src/test/java:/home/testenv/NetBeansProjects/MavenProject/Implementation/target/generated-test-sources/test-annotations: --add-reads example.implementation=ALL-UNNAMED
    
  4. 我们需要使导出的测试类可用于实现模块。将此依赖项添加到您的 :my-impl-module/pom.xml

    <dependency>
        <groupId>com.example</groupId>
        <artifactId>Declaration</artifactId>
        <version>1.0-SNAPSHOT</version>
        <type>test-jar</type>
        <scope>test</scope>
    </dependency>
    
  5. 最后在测试类中,更新导入以指定新的测试包,以访问测试类:my-impl-modulecom.example.common.textmy-common-module

    import com.example.declaration.test.AbstractFooTest;
    import com.example.declaration.Foo;
    import org.junit.Test;
    import static org.junit.Assert.*;
    
    /**
     * Test class inheriting from common module...
     */
    public class FooImplementationTest extends AbstractFooTest { ... }
    

以下是我对新变化的测试结果:mvn clean package

enter image description here

我在 Java 跨模块测试 GitHub 存储库中更新了我的示例代码。我唯一挥之不去的问题,我相信你也一样,是当我将实现模块定义为常规项目而不是模块时,它为什么有效。但是,我改天会玩的。希望我提供的内容能解决您的问题。jar


答案 2

我试图做完全相同的事情,不可能在你的项目结构中同时进行白盒测试和模块测试依赖关系,但我认为我找到了一种替代结构,可以完成你想做的90%的事情:

1/ 白盒测试的问题在于它适用于模块修补,因为与Maven不同,JPMS没有测试VS main的概念。因此,这引发了一些问题,例如不使用测试依赖项,或者不得不用测试依赖项污染模块信息。

2/ 那么,为什么不继续做白盒测试,而是用黑盒测试的maven结构,即:将每个模块X拆分为X和X-test。只有 X 具有模块信息.java,测试在类路径中运行,因此您可以跳过所有这些问题。

我能想到的唯一缺点是(按重要性增加的顺序):

  1. 测试罐不会被模块化,但我认为这是可以接受的(至少现在是这样)。
  2. 您的 maven 模块数量是其两倍,并且您可能不喜欢在另一个 maven 模块中分离测试。
  3. 测试将在类路径中运行,并且在不同的环境中运行测试总是不好的(测试将以比主代码更少的限制运行)。这可以通过烟雾测试或专用的集成测试模块来缓解?“官方模式”尚未出现。

顺便说一句(如果这就是你正在做的事情),我怀疑它是否值得模块化,例如。一个弹簧启动应用程序,因为弹簧本身还没有模块化,所以你会付出代价,但收获很少的好处(但如果你正在写一个lib,那就另当别论了)。

你可以在这里找到一个例子:

a/ 获取示例:

git clone https://github.com/vandekeiser/ddd-metamodel.git

git 签出堆栈溢出

b/ 看一下这个例子:

  1. fr.cla.ddd.metamodel 依赖于 fr.cla.ddd.oo (但测试 maven 模块没有 module-info)
  2. 我在 PackagePrivateOoTest 和 PackagePrivateMetamodelTest 中进行白盒测试
  3. 我有一个测试 Depency OoTestDependency

推荐