ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Corley \(AT/LMI\)" <>
Subject RE: "java.lang.ClassCastException:" error after using <ant> task within ant
Date Fri, 22 Sep 2006 14:01:32 GMT
Hey Steve,
	I'll take your code, and play around with it, but for the moment
I'm going to try and switch the <ant> to an <import> coupled with 2
<antcall> statements. I've got a developer testing it at the moment, and
hopefully he'll get some results from it. I'll post back here if he

Oh by the way, is the code you posted below going to be included as part
of the 2nd edition of java development with ant? I saw smart-frog is in
use. I'm anxious to see if it could integrate into our corporate
environment, but will hold off playing with the current distribution
until the book comes out.


-----Original Message-----
From: Steve Loughran [] 
Sent: 22 September 2006 15:56
To: Ant Users List
Subject: Re: "java.lang.ClassCastException:" error after using <ant> task within ant

David Corley (AT/LMI) wrote:

> I should explain my reasoning for carrying things out the way I do.
> Basically, I've defined a core build.xml for every developer on our 
> site. It allows them to only have to set their classpaths and 
> properties, and everything else will just work for them. So far it's 
> been quite succesful. But we came across a stumbling block where some 
> developers wanted to run tests against code they had just compiled.
> Normally the developers would have stubs for their unit tests, but 
> some developers need to run against a live server. And the server code

> may have just been compiled as part of the build.
> Unfortunately the core build doesn't facilitate the running of any 
> compiled code, aside from the unit tests, which are run with the ant 
> <junit> task.

> So I came up with a workaround, where I allow the developers to do 
> what they like right before the unit testing starts and straight after

> it finishes.
> It means the core build.xml is still untampered, and the used get to 
> run whatever <java> tasks need to be run before testing with their 
> custom junit-setup.xml targets. I suppose I could use <import>....but 
> why should I have to? The <ant>  task should work just fine... No?

<ant> does create a new project, and doesnt return state to the system,
so its not ideal.

I sometimes use import for this, but let people override the junit 
target itself, with different test patterns. We also have a custom task,

<functionaltest> which integrates setup, parallel deployment, a spin 
until the system is running and cleanup

     <sf-functionaltest testTimeout="600" shutdownTime="10">
         <sf-startdaemon-debug failonerror="false" spawn="false"/>
         <socket port="${smartfrog.daemon.port}" server="localhost"/>
           <batchtest todir="${}">
             <fileset dir="${test.classes.dir}">
               <include name="**/unit/*Test.class"/>
               <include name="**/system/**/*Test.class"/>
         <sf-stopdaemon failonerror="false"/>
         <sf-junitreport data="${}"

Notice how we dont even need to tell junit not to fail if the tests 
fail, because the teardown sequence generates the junit report and then 
re throws the junit-initiated failure method, if that is how junit

The LGPL source is available for this if you want it.


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

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

View raw message