maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kalle Korhonen <kalle.o.korho...@gmail.com>
Subject Re: Adding a directory to maven-surefire-plugin's classpath
Date Sat, 02 May 2009 06:57:55 GMT
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 <andrew.bayer@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
> <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