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 Matt Benson
Reply:     <<     11     12     13  

--- "David Corley (AT/LMI)"
<david.corley@(protected)> wrote:

> 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
> succeeds.

<import> and <antcall>?  I can't remember exactly
-why- you needed the new project context that comes
with <ant>/<antcall>, but if you're not _sure_ you
need it you really might want to try replacing
<antcall>s with macro invocations.  In my experience
you can accomplish 99% of sane tasks with the latter
and without taking the memory/performance hit
associated with <ant(call)?>.

-Matt
>
> 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.
>
> /Dave
>
> -----Original Message-----
> From: Steve Loughran [mailto:stevel@(protected)]
> Sent: 22 September 2006 15:56
> To: Ant Users List
> Subject: Re: "java.lang.ClassCastException:
> org.apache.tools.ant.types.Path" 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.
>
> 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)
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> user-unsubscribe@(protected)
> For additional commands, e-mail:
> user-help@(protected)
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

---------------------------------------------------------------------
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.