Sadly, no - that gets passed to the JVM running the tests. The problem here is that I need it in the classpath of the Maven JVM itself - Surefire's calling junit's Request.aClass(testClass).getRunner() on our test classes before it forks. Really, I need to get the developer to rewrite the code, but hey. =)
A. On Fri, May 1, 2009 at 2:34 PM, Kalle Korhonen <[email protected]>wrote: > Hey Andrew, > > would these help? > > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-surefire-plugin</artifactId> > <configuration> > <forkMode>always</forkMode> > <workingDirectory>target</workingDirectory> > <argLine>-Djava.library.path=lib</argLine> > <additionalClasspathElements> > > > <additionalClasspathElement>${project.build.directory}/conf</additionalClasspathElement> > </additionalClasspathElements> > </configuration> > > Kalle > > PS. And you know you can look at our poms if you like... > > > On Fri, May 1, 2009 at 2:21 PM, Andrew Bayer <[email protected]> > wrote: > > > 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. > > > > > >
