ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <>
Subject Re: svn commit: r568040 - /ant/core/trunk/WHATSNEW
Date Tue, 21 Aug 2007 14:07:43 GMT
On 8/21/07, Dominique Devienne <> wrote:
> On 8/21/07, <> 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) {
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.

> Thanks, --DD
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message