ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: "java.lang.ClassCastException: org.apache.tools.ant.types.Path" 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.

OK
> 
> 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">
       <application>
         <sf-startdaemon-debug failonerror="false" spawn="false"/>
       </application>
       <probe>
         <socket port="${smartfrog.daemon.port}" server="localhost"/>
       </probe>
       <test>
         <sf-junit
             fork="true"
             includeantruntime="true"
             haltonfailure="true"
             >
           <classpath
               refid="tests.run.classpath"/>
           <batchtest todir="${test.data.dir}">
             <fileset dir="${test.classes.dir}">
               <include name="**/unit/*Test.class"/>
               <include name="**/system/**/*Test.class"/>
             </fileset>
           </batchtest>
         </sf-junit>
       </test>
       <teardown>
         <sf-stopdaemon failonerror="false"/>
         <sf-junitreport data="${test.data.dir}"
             reports="${test.reports.dir}"
             />
       </teardown>
     </sf-functionaltest>

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.

-steve



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message