Hi - I'm working on transitioning a large multi-module project from Ant to Maven, and have encountered a truly bizarre use case for Surefire. The unit tests in a number of the modules use a fairly elaborate Junit runner framework developed here - logging, configuration file locations, etc are all determined through the runner. We'd been running each test forked on its own in the existing Ant system - but upon moving to Maven and using fork="once", we discovered that in some cases, tests stepped on each other. However, when we try to run tests using our Junit runner with fork="always", the tests never actually run - we end up with this stacktrace:
java.lang.IllegalStateException: Could not find 'conf/' directory in the classpath. In order to find the home directory in the classpath a directory called 'conf/' must be in the root of the classpath and can not be in a jar. at com.cisco.ccbu.infra.Environment.findHomeAbsPathInClasspath(Environment.java:204) at com.cisco.ccbu.infra.Environment.getHomeDirectory(Environment.java:132) at com.cisco.ccbu.infra.Environment.getConfigurationDirectory(Environment.java:160) at com.cisco.ccbu.infra.properties.PropertyManager.init(PropertyManager.java:152) at com.cisco.ccbu.infra.properties.PropertyManager.<clinit>(PropertyManager.java:106) at com.cisco.ccbu.infra.serviceability.CustomLogMessages.reloadCustomizedMessages(CustomLogMessages.java:123) at com.cisco.ccbu.infra.serviceability.CustomLogMessages.<clinit>(CustomLogMessages.java:97) at com.cisco.ccbu.infra.serviceability.LogMsg.initLevel(LogMsg.java:211) at com.cisco.ccbu.infra.serviceability.LogMsg.<init>(LogMsg.java:489) at com.cisco.ccbu.infra.serviceability.LogMsg.<init>(LogMsg.java:441) at com.cisco.ccbu.infra.junit.runners.Infrastructure.<clinit>(Infrastructure.java:191) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) at org.apache.maven.surefire.junit4.JUnit4TestSet.<init>(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.getTestSets(SurefireBooter.java:448) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesForkPerTestSet(SurefireBooter.java:399) at org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:249) at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:492) The problem here is that the runner for each test gets initialized when fork="always", but our runner depends on there being a directory in the classpath with a "conf" subdirectory. In our builds, there is a target/test-classes/conf directory, so the actual test execution works alright, but the classpath the Surefire plugin itself runs in does not work here. I can't find a way to get a directory with a conf subdirectory onto the maven-surefire-plugin classpath - it needs to be an actual filesystem directory, so I can't just add a jar to maven-surefire-plugin's dependencies. We can prevent it from ever checking for that conf directory in the classpath if we've set a system property to point to a directory with a conf subdir, but since we can't set system properties for the maven process on a per-pom basis, I'm not happy doing that if I can avoid it. And we wouldn't want that system property to be carried over into the actual unit tests - I know Surefire 2.4.3 with Maven 2.0.10 doesn't transfer the Maven process's system properties to the tests, but I can't tell if that's a bug or intended. So yeah - I'm stumped as to what to do about this - does anyone have any ideas? A.