需要澄清maven配置文件中资源定义的影响

Question

在如下结构的Maven Multi Module Project中：

P // parent project
  * A // first module
  * B // second module, containing the test in question

A的pom.xml包含：

 <profile>
   <id>theProfile</id>
     <build>
       <resources>
         <resource>
           <directory>src/main/ctx/someDir</directory>
             <filtering>true</filtering>
         </resource>
         <resource>
         <resource>
           <directory>src/main/resources</directory>
         </resource>
       </resources>
     <build>
   </profile>         

当运行完整的项目P并激活此配置文件时， src/test/resources的可用性是否在B测试期间以任何方式受到影响的类路径的一部分？

如果是，以何种方式，以及如何更改定义以便给定资源

a）纯粹是额外的

b）仅影响定义它们的A.

如果是，那么src/main/resources部分是多余的吗？

Answer 1

简短回答：不，不。

在流程资源阶段，项目A中的资源将被复制到A/target/classes中。 配置文件唯一要做的就是将更多资源复制到target/classes 。 也就是说，它还将从src/main/ctx/someDir复制（和过滤）文件。

B的测试类路径保持不变。 假设B依赖于A，则其测试类路径将包括A.jar，其将包括A /目标/类的内容。 您可以使用mvn dependency:build-classpath来检查这一点。 但是，尽管类路径相同，但A的类路径条目的内容将不同。

我不确定你为什么提到src/test/resource （我假设你输错了src/test/resources ）。 使用<testResources>元素单独管理测试资源。 如果你的意思是A/src/test/resources ，那么不，它们不会出现在B的测试类路径中。 如果你的意思是B/src/test/resources ，那么是的，它们将出现在B的测试类路径中。 因此，激活配置文件不会对其产生任何影响。

指定src/main/resources并不是多余的。 如果要包含<resources>元素，则需要包含项目中包含资源的所有目录。

Answer 2

TL; DR A）否; B）否; 如果您的<resources>是<resources combine.children="append">那么您可以省略它，但是如上所述，否

答案很长

如果从根运行构建，并假设B依赖于A.

您获得的类路径取决于您将整个反应器前进到的阶段。

如果阶段在生命周期的package阶段之前，则类路径将引用${project.build.outputDirectory}目录以获取reactor内的依赖关系

如果阶段在生命周期的package阶段之后或之后，则类路径将引用构造的JAR文件，例如${project.build.directory}/${project.build.finalName}.jar

那么给你一些具体的例子：

$ mvn compile

这在P中无效，因为P是<packaging>pom</packaging> ，默认情况下，打包在install之前不会将任何[类路径相关]插件绑定到生命周期阶段。

当我们点击A时它将列出编译类路径中的所有A的依赖项，因为这些都不是来自反应堆，它们将从本地缓存（即~/.m2/repository ）解析，所以如果A使用log4j，你将有一个类似的编译类路径

${JAVA_HOME}/lib/rt.jar:~/.m2/repository/log4j/log4j/1.2.16/log4j-1.2.16.jar

我们在编译后没有指定阶段，因此不会调用需要测试类路径的插件，因此此时不相关。

现在我们转到B. B的依赖包括A，所以它将引用A的主要工件（因为jar:jar没有运行将指向A的${project.build.outputDirectory} ）B的编译类路径将看起来像这样的小事

${JAVA_HOME}/lib/rt.jar:~/.m2/repository/log4j/log4j/1.2.16/log4j-1.2.16.jar
:./A/target/classes

[注意：当我们从P目录调用时，当前目录是P的${basedir}所以B的${basedir}的值将是./B ]

虽然B自己的依赖关系可能会改变类路径，具体取决于其pom中依赖关系的顺序，以及它是否对传递依赖关系应用排除或版本覆盖

好。 这很简单，让我们开始......接下来我们将生命周期提升到test阶段

$ mvn test

P和以前一样有着相同的故事

A具有与以前相同的编译故事。 当我们进入test-compile阶段时，将使用以下类路径编译测试（假设使用junit进行测试）

${JAVA_HOME}/lib/rt.jar:~/.m2/repository/log4j/log4j/1.2.16/log4j-1.2.16.jar
:./A/target/classes:~/.m2/repository/junit/junit/4.10/junit-4.10.jar

[我可能会对元素的排序略有错误，因为我需要深入研究mvn -X来确认，但校长是正确的]

当我们进入test阶段时， surefire:test将构建测试类路径。 默认情况下，它将测试依赖项置于非测试依赖项之前，但它是可配置的。 所以A的测试类将使用类似于此的类路径执行

${JAVA_HOME}/lib/rt.jar:./A/target/test-classes:~/.m2/repository/junit/junit/4.10/junit-4.10.jar
:~/.m2/repository/log4j/log4j/1.2.16/log4j-1.2.16.jar:./A/target/classes

这允许在测试类路径中使用匹配资源来覆盖生产默认值以使代码可测试等。

B的编译类路径与之前相同。 我也投入了B依赖于不同版本的JUnit。 test-compile类路径不应该是一个惊喜

${JAVA_HOME}/lib/rt.jar:~/.m2/repository/log4j/log4j/1.2.16/log4j-1.2.16.jar
:./A/target/classes:./B/target/classes
:~/.m2/repository/junit/junit/4.11/junit-4.11.jar

现在事情变得有趣了，B的classpath由surefire构建（再次测试范围的依赖关系的排序可以修改，所以假设你使用默认值）。 A的测试类路径不可传递，因此不会暴露给B.

${JAVA_HOME}/lib/rt.jar:./B/target/test-classes
:~/.m2/repository/junit/junit/4.11/junit-4.11.jar
:~/.m2/repository/log4j/log4j/1.2.16/log4j-1.2.16.jar
:./A/target/classes:./B/target/classes

最后，让我们进入package阶段，看看它如何影响类路径。

$ mvn package

P与以前相同。

A实际上与之前相同，因为它的所有依赖都不是来自反应堆内部。 但关键是当jar:jar在package阶段运行时它会替换暴露的类路径...这将影响B如何看到A.

B的类路径构造与以前相同，除了现在B看到A的.jar而不是A的编译类。 所以B的compile类路径将是

${JAVA_HOME}/lib/rt.jar:~/.m2/repository/log4j/log4j/1.2.16/log4j-1.2.16.jar
:./A/target/A-1.0-SNAPSHOT.jar

B的test-compile类路径看起来像这样

${JAVA_HOME}/lib/rt.jar:~/.m2/repository/log4j/log4j/1.2.16/log4j-1.2.16.jar
:./A/target/A-1.0-SNAPSHOT.jar:./B/target/classes
:~/.m2/repository/junit/junit/4.11/junit-4.11.jar

B的test类路径看起来像这样：

${JAVA_HOME}/lib/rt.jar:./B/target/test-classes
:~/.m2/repository/junit/junit/4.11/junit-4.11.jar
:~/.m2/repository/log4j/log4j/1.2.16/log4j-1.2.16.jar
:./A/target/A-1.0-SNAPSHOT.jar:./B/target/classes

现在只是为了给你最后的图片

$ mvn install -DskipTests
$ mvn test -f B/pom.xmml

在Maven的第二次调用中，我们只使用单个模块recactor运行（即B是反应器中唯一的模块），现在A将从本地缓存中解析，因此我们得到的测试类路径就像

${JAVA_HOME}/lib/rt.jar:./B/target/test-classes
:~/.m2/repository/junit/junit/4.11/junit-4.11.jar
:~/.m2/repository/log4j/log4j/1.2.16/log4j-1.2.16.jar
:~/.m2/repository/com/mydomain/myproject/A/1.0-SNAPSHOT/A-1.0-SNAPSHOT.jar
:./B/target/classes

现在希望这有点澄清了Maven的类路径之谜。

你的个人资料如何融入这个...他们对你的课程路径没有任何帮助。 他们所做的是将文件复制到${project.build.outputDirectory 。

当A到达process-resources阶段时，它会将所有已定义的resources复制到${project.build.outputDirectoy}以便

$ mvn package -PtheProfile

将构造完全相同的类路径， 但 ./A/src/main/ctx/someDir的文件将被复制并过滤到A的${project.build.outputDirectoy}同时保留其目录结构和./A/src/main/resources的文件./A/src/main/resources将被复制到A的${project.build.outputDirectoy}而不进行过滤，同时保留其目录结构。 然后当我们点击package阶段时jar:jar会将所有这些文件再次压入.jar 。

我希望这个答案可以帮助你更好地理解发生了什么...我也希望你开始明白为什么使用配置文件来影响构建的工件会导致头痛，例如

$ mvn clean install -PtheProfile -DskipTests
$ mvn test -f B/pom.xml

会有不同的结果

$ mvn clean install -DskipTests
$ mvn test -f B/pom.xml

因为当工件安装到本地存储库时，本地存储库缓存不知道哪些配置文件是活动的，所以第一种情况从第二种情况构建不同的A.jar ...

但这更多地暗示了您可能遇到的未来问题，以及为什么我们提倡坚持使用Maven方式并避免使用配置文件来修改可传递暴露的类路径或构建的工件。 使用配置文件修改test类路径非常有用（例如，当测试在JDK1.5上运行而JDK1.6与JDK1.7相比时，您可能需要修改测试的类路径...这是正常的，因为测试类路径是不可传递的）