That's interesting what you said about <antcall>. I didn't realise it would eat up so much resources. I actually would have thought that <antcall> actually worked as a type of "goto" that simply jumped to the target. I guess not.
I was curious as to how I would implement a macro to call a specific target though? I've done something similar with ant-contrib, but I think that's overkill for what I want to do here. The <import> and <antcall> are simple to implement. Hopefully there won't be any problems with them. As I said, I'll post back to let y'all know if it works as a replacement for <ant> /Dave -----Original Message----- From: Matt Benson [mailto:[EMAIL PROTECTED] Sent: 22 September 2006 16:29 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)" <[EMAIL 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:[EMAIL 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: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
