Need clarification on the effect of resource definitions in maven profiles

Question

In a Maven Multi Module Project structured like this:

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

the pom.xml of A contains this:

 <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>         

When the complete project P is run and this profile is activated is the availability of src/test/resources as part of the classpath during tests of B affected in any way?

If yes, in which way, and how to change the definition so the given resources are

a) purely additional

b) affect only A in which they are defined.

If No, is the src/main/resources part superfluous?

Answer 1

TL;DR A) No; B) No; if your <resources> was <resources combine.children="append"> then you could omit it, but as written, No

Long answer

If you run the build from the root, and assuming that B depends on A

The classpath you get depends on the phase that you progress the whole reactor to.

Where the phase is before the package phase of the lifecycle, the classpath will reference the ${project.build.outputDirectory} directory for dependencies within the reactor

Where the phase is on or after the package phase of the lifecycle, the classpath will reference the constructed JAR file, e.g. ${project.build.directory}/${project.build.finalName}.jar

So to give you some concrete examples:

$ mvn compile

That will do nothing in P because P is a <packaging>pom</packaging> and by default that packaging does not bind any [classpath relevant] plugins to lifecycle phases prior to install.

When we hit A it will list up all of A's dependencies in the compile classpath, since none of these come from the reactor, they will be resolved from the local cache (i.e. ~/.m2/repository) so if A uses log4j, you will have a compile classpath like

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

We have not specified a phase after compile, so no plugins requiring the test classpath will be invoked, so not relevant at this point in time.

Now we move to B. B's dependencies include A, so it will reference the main artifact for A which (as jar:jar hasn't run will be pointing to A's ${project.build.outputDirectory}) B's compile classpath will look a little something like this

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

[Note: as we invoked from the P directory the current directory is the P's ${basedir} so B's value of ${basedir} will be ./B]

Though B's own dependencies may alter the classpath depending on the order of dependencies in its pom and whether it applies exclusions or version overrides on the transitive dependencies

OK. That was simple enough to get us started... next we move up the lifecycle to the test phase

$ mvn test

P has the same story as before

A has the same compile story as before. When we hit the test-compile phase the tests will be compiled with the following classpath (assuming using junit for tests)

${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

[I may have the ordering of elements slightly wrong as I'd need to dig into mvn -X to confirm, but the principal is correct]

When we get to the test phase, surefire:test will build up the test classpath. By default it puts test dependencies ahead of non-test dependencies but it is configurable. So A's test classes will execute with a classpath somewhat like this

${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

This allows for things like using matching resources in the test classpath to override the production defaults in order to make the code testable, etc.

B's compile classpath is the same as before. I am also throwing in that B depend on a different version of JUnit. The test-compile classpath shouldn't be a surprise

${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

Now things get interesting, B's classpath as constructed by surefire (again the ordering of test scoped dependencies can be modified, so assuming you are using the default). A's test classpath is not transitive so will not be exposed to 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

Finally, let's go as far as the package phase and see how that effects the classpath.

$ mvn package

P is the same as before.

A is actually the same as before, because none of its dependencies come from within the reactor. But the key thing here is that when jar:jar runs in the package phase it replaces the exposed classpath... this will effect how B sees A.

B's classpaths are constructed the same as before, except that now B sees A's .jar and not A's compiled classes. So B's compile classpath will be

${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's test-compile classpath will look something like this

${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's test classpath will look something like this:

${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

Now just to give you the final picture

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

In the second invokation of Maven where we are just running with a single module recactor (i.e. B is the only module in the reactor), now A will be resolved from the local cache, so we get the test classpath something like

${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

Now hopefully that has somewhat clarified the mystery of the classpaths from Maven.

How do your profiles mix into this... well they do nothing to your classpath. What they do instead is copy files into ${project.build.outputDirectory.

When A reaches the process-resources phase it will copy all the defined resources into ${project.build.outputDirectoy} so

$ mvn package -PtheProfile

Will construct the exact same classpaths but the files in ./A/src/main/ctx/someDir will be copied with filtering into A's ${project.build.outputDirectoy} while retaining their directory structure and the files in ./A/src/main/resources will be copied in to A's ${project.build.outputDirectoy} without filtering while retaining their directory structure. Then when we hit the package phase jar:jar will just slurp up all those files into the .jar again.

I hope this answer helps you understand what is going on better... I also hope you are starting to see why using profiles to affect the built artifacts can result in headaches, e.g.

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

will have different results from

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

as the local repository cache does not know what profiles were active when the artifact was installed into the local repository so the first case builds a different A.jar from the second case...

But that is more of a hint at future issues you may encounter and why we advocate sticking to the Maven way and avoiding the use of profiles to modify either the transitively exposed classpath or the built artifact. The use of profiles to modify the test classpath though is quite useful (for example when the tests run on JDK1.5 vs JDK1.6 vs JDK1.7 you may need to modify the classpath for the tests... this is OK as the test classpath is non-transitive)

Answer 2

Short answer: No, and no.

The resources in project A will be copied into A/target/classes, during the process-resources phase. The only thing that the profile is doing is to copy more resources into target/classes. That is, it will also copy (and filter) files from src/main/ctx/someDir.

The test classpath of B stays the same. Assuming B depends on A, then its test classpath will include A.jar, which will include the content of A/target/classes. You can check this using mvn dependency:build-classpath. However, although the classpath is the same, the content of the classpath entry for A will be different.

I'm not sure why you mention src/test/resource (I assume you typo'd src/test/resources). Test resources are managed separately using the <testResources> element. If you mean A/src/test/resources, then no, they won't appear in B's test classpath. If you mean B/src/test/resources, then yes, they will appear in B's test classpath. So it's not affected in any way by activating the profile.

Specifying src/main/resources isn't superfluous. If you're going to include a <resources> element, then it needs to include all the directories containing resources in your project.