Java Mailing List Archive

http://www.ant-tasks.com/

Apache Ant Archive

» Ant Users List
» Ant Developers List
"java.lang.ClassCastException: org.apache.tools.ant.types.Path " error after

"java.lang.ClassCastException: org.apache.tools.ant.types.Path " 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.

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


©2008 ant-tasks.com - Jax Systems, LLC, U.S.A.