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?
TL;DR A) No; B) No; if your
<resources>was<resources combine.children="append">then you could omit it, but as written, NoLong 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
packagephase of the lifecycle, the classpath will reference the${project.build.outputDirectory}directory for dependencies within the reactorWhere the phase is on or after the
packagephase of the lifecycle, the classpath will reference the constructed JAR file, e.g.${project.build.directory}/${project.build.finalName}.jarSo to give you some concrete examples:
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 toinstall.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 likeWe 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:jarhasn’t run will be pointing to A’s${project.build.outputDirectory}) B’s compile classpath will look a little something like this[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
testphaseP has the same story as before
A has the same compile story as before. When we hit the
test-compilephase the tests will be compiled with the following classpath (assuming using junit for tests)[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
testphase,surefire:testwill 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 thisThis 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-compileclasspath shouldn’t be a surpriseNow 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.
Finally, let’s go as far as the
packagephase and see how that effects the classpath.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:jarruns in thepackagephase 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
.jarand not A’s compiled classes. So B’scompileclasspath will beB’s
test-compileclasspath will look something like thisB’s
testclasspath will look something like this:Now just to give you the final picture
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
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-resourcesphase it will copy all the definedresourcesinto${project.build.outputDirectoy}soWill construct the exact same classpaths but the files in
./A/src/main/ctx/someDirwill be copied with filtering into A’s${project.build.outputDirectoy}while retaining their directory structure and the files in./A/src/main/resourceswill be copied in to A’s${project.build.outputDirectoy}without filtering while retaining their directory structure. Then when we hit thepackagephasejar:jarwill just slurp up all those files into the.jaragain.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.
will have different results from
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
testclasspath 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)