On 8/21/07, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On 8/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Modified: ant/core/trunk/WHATSNEW
> >
> > + means that tasks may now have nested conditions just by implementing
> > + the Condition interface, rather than extending ConditionBase.
>
> I'm not sure I'm following here Peter. How does implementing Condition
> (which has only an eval() method) translate into accepting any nested
> conditions?
It means that one can do:
public class Example {
List<Condition> conditions ;
public void add(Condition c) {
conditions.add(c);
}
}
and pick up conditions like and, or etc.
up to now, one has to extend conditionBase to do this,
>
> > + means that the use of namespaces for some of the selectors introduced
> > + in Ant 1.7.0 is no longer necessary.
>
> Aren't we making it more difficult (impossible?) to validate Ant build
> files by allowing an extensible set of nested elements without the use
> of namespaces?
Not necessary.
The core ant conditons, selectors would be known (per release) and
one could easily write an RelaxNG description of them. (this is no
different for the refection based elements).
For third party antlibs, they would use their own namespace.
However, ant does contain things like macrodef and presetdef which
will modify the current scheama, and <typedef/taskdef and the others>
do not enforce placing the new element in a different namespace.
Peter
>
> Thanks, --DD
>
> ---------------------------------------------------------------------
> 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]
