ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Issue with JUnit, forking, & classloading?
Date Tue, 25 Jun 2002 17:27:53 GMT

----- Original Message -----
From: <>
To: <>
Sent: Tuesday, June 25, 2002 8:50 AM
Subject: Issue with JUnit, forking, & classloading?


I am experiencing an interesting problem when using Ant 1.5Beta3 and
JUnit3.7 (on Windows2000).

I have a <junit> task that runs my unit tests.  I have chosen to set
fork="no" so that the tests run a little faster (I can set fork="yes"
for the nightly build).

I have set up 2 formatters one of type="xml" and one of type "plain".
Both of these are reporting to files.

My unit tests have import statements including some XML (SAX) classes,
that should be loaded from j2ee.jar (from J2EE1.3.0, required by our app
server) that is in my test classpath.

What seems to be happening is that JUnit is correctly finding and
loading the classes from j2ee.jar, but when the task's XML formatter object
tries to start writing it's output it's using the classes loaded from
j2ee.jar rather than the xml-apis/xalan jars in the Ant lib, and so I
get a java.lang.LinkageError error.


(sorry about not indenting your comments above; outlook express is being
petulant today)

There is a funny in ant1.5 that I thought I'd fixed before beta-3, which
stems from the migration from crimson to xerces; we didnt update the
manifest till beta3, so if you had the xmlformatter and fork=true, you got a
class not found exception.

Your problem only happens when fork=false, so it is similar but different.

1. try setting includeantruntime=true
2. can you switch to using xerces over crimson

>As an aside, is there anyway to tell the <junit> task to fork into just
>one JVM, rather than one per test class found?  That way the JVM would
>be 'clean' for the unit testing, and would not rely on the classes
>already loaded by the system or ant classloaders, but would not take as
>long as starting a number of JVMs?

not yet, no.

There is some work on redoing <junit> more cleanly; IMO it should not have
to be that the formatter runs in the same JVM as the test cases; they should
be separate jvms talking to each other over RMI, which would even let you
run tests on a remote system.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message