Whoops - left off "classpath" from the subject. A.
On Fri, May 1, 2009 at 1:27 PM, Andrew Bayer <[email protected]> wrote: > 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. >
