ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: "java.lang.ClassCastException:" error after using <ant> task within ant
Date Fri, 22 Sep 2006 13:55:47 GMT
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 ended.

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


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

View raw message