Java Mailing List Archive

Apache Ant Archive

» Ant Users List
» Ant Developers List
"java.lang.ClassCastException: " error after

"java.lang.ClassCastException: " error after

2006-09-22       - By Steve Loughran
Reply:     1     2     3     4     5     6     7     8     9     10     >>  

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: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)

©2008 - Jax Systems, LLC, U.S.A.