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:40:55 GMT
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
<kalle.o.korhonen@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 <andrew.bayer@gmail.com>
> wrote:
>
> > 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