maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Bayer <andrew.ba...@gmail.com>
Subject Re: Adding a directory to maven-surefire-plugin's classpath
Date Fri, 01 May 2009 21:21:38 GMT
Whoops - left off "classpath" from the subject.

A.

On Fri, May 1, 2009 at 1:27 PM, Andrew Bayer <andrew.bayer@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message