ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: <macrodef> and local
Date Wed, 23 Jun 2004 17:43:46 GMT
--- Magesh Umasankar <umagesh@apache.org> wrote:
> From:       Peter Reilly <peter.reilly () corvil !
> com>
> Date:       2004-06-23 16:23:48
> 
> > are some cases where true local properties would
> be more easily
> 
> like...?
> 

like anytime you have to make two passes at some data
to get a property set exactly the way you want it.  Or
you want to pass some data, formatted just so, to a
task... MANY TIMES, like for each file in a fileset. 
Yes, you could write a Java task, or even a
<scriptdef>, but one of the nicest things about
<macrodef> is that anyone familiar with Ant can use it
to build more complex behavior out of existing tasks. 
This could encourage task developers to keep the
operations of their tasks as atomic as possible and
increase the chance of reusability of pieces.  I'm
sure I don't need to illustrate the ease-of-use of
<macrodef> vs. using Ant task classes from custom task
code?  So no, having local variables does not give us
anything we can't do, but it does save us having to
pollute the Project properties with e.g. 500 useless
properties.

> > The <break> task is interesting. I am concerned
> however about
> > how third party task containers would work with
> it.
> 
> If the third-party container would like to support
> the break task,
> they would need to catch BreakException and handle
> it in the place 
> where they iterate over their nested tasks and
> execute them.  
> BreakException extends from BuildException.  It gets
> thrown by 
> the <break> task if it decides that the condition to
> break is met.
> 
What if the third-party container would NOT like to
support the <break> task?  This starts to change the
intent of what a Task does, no?

> Inside Ant, we'd need to modify Target, Sequential,
> and Parallel
> at obvious places to support <break>
> 
Sounds like <break> is <fail> with <ac:try>.  If we
were going to include flow control, <ac:if> would
require less support programming.

> > Peter
> 
> Cheers,
> Magesh

-Matt


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

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


Mime
View raw message