What is Maven doing with my testclasspath

Question

I'm having issues with a test, which when executed in maven fails to initialize log4j, although a valid log4j.properties is in src/test/resources and therefore should end up on the classpath of the test. But it doesn't, i.e. log4j prints only

log4j:WARN No appenders could be found for logger (org.springframework.test.context.junit4.SpringJUnit4ClassRunner).
log4j:WARN Please initialize the log4j system properly.

In order to debug the problem I printed the classpath from the test itself, using the code here

But instead of a lengthy list of jars and paths I just get

/<projectpath>/target/surefire/surefirebooter6226797341642271676.jar

So my questions are:

WTF is maven doing with the classpath?
Why doesn't my log4j.properties end up on the classpath?
How do I debug this?

Note: In Eclipse I can run the test just fine and everything works as expected.

Another note: the maven project is a multimodule project and I'm only executing a single test from a single submodule, with a commandline like this:

mvn -U -Dtest=de.company.project.SomeTest clean test

If you are trying to run a single module out of a multi-module build you need to go with -pl and maybe -amd instead of going into the appropriate folder. Furthermore it would be helpful to see the full pom.xml's to see where the problem might be. — khmarbaise, Mar 19 '13 at 10:45
While the options are certainly helpfull, I don't see how they relate to the question at hand!? The major difference seems to be that -pl will actually use the local build artefacts, while changing into the directory uses artifacts from the repository. — Jens Schauder, Mar 19 '13 at 11:44

carlspring · Accepted Answer · 2013-03-19T15:58:22.297

Have a good look at the maven-surefire-plugin. By default it creates a jar stuffed with your entire classpath. This is controlled by the useManifestOnlyJar option. This works around the problem of Windows having a classpath limit of 1024 (quoting off the top of my head). Under Linux you wouldn't really feel this pain much as the limit is much higher.

If you are forking the maven-surefire-plugin, it will use a different classpath than the one you're running Maven (and the compilation).

Debugging this kind of crappy situation can be done as follows:

In one of your tests add a loop that lists all the environment variables along with the java system properties.

Debug the tests:

mvn -Dmaven.surefire.debug="-Xdebug \
    -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=9001 \
    -Xnoagent" \
    test

score 0 · Answer 2 · edited May 23 '17 at 12:04

I found the answer to question 1.

Maven creates the jar with the weird name on the fly and just puts a MANIFEST.MF file in there. That file contains the classpath, and the main class to be started.

This also answers to some extend question 3.

You can copy that jar file somewhere else, while maven is running, so it does not delete it once it is finished. Then you can examine it as long as you want. Turns out my log4.properties is on the classpath (the target directories for the testclasses is there and the properties files is in that directory ....)

Leaves me with question 2.

It turned out somewhere in the forest of pom.xmls the system property log4j.configuration was set to a rather useless value. Setting that value back to the propervalue as described here solved my immediate problem.

Now I just have to find the broken spot in our poms, but that's a story for a different day.

What is Maven doing with my testclasspath

2 Answers2