Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of andrew.bayer@gmail.com
 designates 74.125.46.156 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:from:date:message-id:subject:to:content-type;
        b=XD4zMpdZq/8mk/hWzQzhQUeNCI9geLSyj3cpLKm9WZ9j1qR0yvvorWsL1bdKpgVL4b
         rnhY3GPV4wFdUhJKQP3iiHweLxoVJ+aQWJKFhcii8VEl870L6UggVhhePv89BFIji1hk
         0rDfLep8mrOMsELV9m8hG0JHYvZ4ftTGDBWSw=
MIME-Version: 1.0
From: Andrew Bayer <andrew.bayer@gmail.com>
Date: Fri, 1 May 2009 13:27:22 -0700
Message-ID: <cf516af70905011327head5f51wd29ae1acd24464fe@mail.gmail.com>
Subject: Adding a directory to maven-surefire-plugin's
To: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=001e680f1038b3b9cb0468dfa478

--001e680f1038b3b9cb0468dfa478
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

--001e680f1038b3b9cb0468dfa478--