You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Andrew Bayer <an...@gmail.com> on 2009/05/01 23:21:38 UTC
Re: Adding a directory to maven-surefire-plugin's classpath
Whoops - left off "classpath" from the subject.
A.
On Fri, May 1, 2009 at 1:27 PM, Andrew Bayer <an...@gmail.com> 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.
>
Re: Adding a directory to maven-surefire-plugin's classpath
Posted by Kalle Korhonen <ka...@gmail.com>.
Ah all the wonderful tricks people sometimes resort to. Maybe setting the
systemproperties for surefire then?
http://maven.apache.org/plugins/maven-surefire-plugin/examples/system-properties.html-
though no guarantees how it behaves.
Kalle
On Fri, May 1, 2009 at 2:40 PM, Andrew Bayer <an...@gmail.com> wrote:
> 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
> <ka...@gmail.com>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 <an...@gmail.com>
> > wrote:
> >
> > > Whoops - left off "classpath" from the subject.
> > >
> > > A.
> > >
> > > On Fri, May 1, 2009 at 1:27 PM, Andrew Bayer <an...@gmail.com>
> > > 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.
> > > >
> > >
> >
>
Re: Adding a directory to maven-surefire-plugin's classpath
Posted by Andrew Bayer <an...@gmail.com>.
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
<ka...@gmail.com>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 <an...@gmail.com>
> wrote:
>
> > Whoops - left off "classpath" from the subject.
> >
> > A.
> >
> > On Fri, May 1, 2009 at 1:27 PM, Andrew Bayer <an...@gmail.com>
> > 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.
> > >
> >
>
Re: Adding a directory to maven-surefire-plugin's classpath
Posted by Kalle Korhonen <ka...@gmail.com>.
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 <an...@gmail.com> wrote:
> Whoops - left off "classpath" from the subject.
>
> A.
>
> On Fri, May 1, 2009 at 1:27 PM, Andrew Bayer <an...@gmail.com>
> 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.
> >
>