> From: Matt Benson [mailto:[EMAIL PROTECTED]
>
> --- Magesh Umasankar <[EMAIL PROTECTED]> 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.
>
I am 100% with you on users having to come up with names for
500 diferent properties that they may need internally to their tasks
at different points of the build. (I for one have had such a problem).
However, if you do not have to come up with such names, and you do not
need to be aware of what those names are, do you really care whether
these things persists in the execution environment or not.
> > > 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?
>
Here I agree. If we were to have such a <break/> task
I would probably prefer to have it as part of a formal
construct and not plugged into the current sequential.
For example:
<block>
....
<break/>
....
</block>
I would go a step further and allow desingnating which block to break
by something like:
<block id="a">
...
<block id="b">
....
<break refid="a"/>
....
</block>
</block>
This is quite much in the spirit of structured programming and
by not overloading <sequential/> there is no issue about
third party stuff.
Of course, the definition of block is quite trivial
(just a sequential with a try/catch). And in my opinion
BreakException MUST be a subclass of BuildException.
Since for example <antcontrib:if> may not be interested on it.
> > 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.
>
I am all for getting some of antcontrib ideas <if> <try> <switch>
etc into the mayline. We all use them all the time.
That does not mean that we need to accept everything, but
I think that with the current level of experience we should be able
to pick from there the constructs that people want and use today.
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
