You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by pe...@apache.org on 2007/08/21 11:42:23 UTC
svn commit: r568040 - /ant/core/trunk/WHATSNEW
Author: peterreilly
Date: Tue Aug 21 02:42:22 2007
New Revision: 568040
URL: http://svn.apache.org/viewvc?rev=568040&view=rev
Log:
adding componentdef to WHATSNEW
Modified:
ant/core/trunk/WHATSNEW
Modified: ant/core/trunk/WHATSNEW
URL: http://svn.apache.org/viewvc/ant/core/trunk/WHATSNEW?rev=568040&r1=568039&r2=568040&view=diff
==============================================================================
--- ant/core/trunk/WHATSNEW (original)
+++ ant/core/trunk/WHATSNEW Tue Aug 21 02:42:22 2007
@@ -10,6 +10,17 @@
task for registering delegates and/or replacing the registered PropertyHelper
instance. Bugzilla report 42736.
+* Added a restricted form of typedef called <componentdef>. This allows
+ definition of elements that can only be within tasks or types. This
+ method is now used to define conditions, selectors and selectors. This
+ means that tasks may now have nested conditions just by implementing
+ the Condition interface, rather than extending ConditionBase. It also
+ means that the use of namespaces for some of the selectors introduced
+ in Ant 1.7.0 is no longer necessary.
+ Implementing this means that the DynamicElement work-around introduced
+ in Ant 1.7.0 has been removed.
+ Bugzilla report 40511.
+
Fixed bugs:
-----------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r568040 - /ant/core/trunk/WHATSNEW
Posted by Dominique Devienne <dd...@gmail.com>.
On 8/21/07, Peter Reilly <pe...@gmail.com> wrote:
> On 8/21/07, Dominique Devienne <dd...@gmail.com> wrote:
> > On 8/21/07, peterreilly@apache.org <pe...@apache.org> 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,
OK, makes sense now, thanks. One still has to accept nested elements
of a given type, as usual, and implementing Condition for Example is
not necessary, and unrelated. For a moment there I thought some new
magic had crept into Ant ;-)
PS: It's put the composed condition into an And or Or condition rather
than a List.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r568040 - /ant/core/trunk/WHATSNEW
Posted by Peter Reilly <pe...@gmail.com>.
On 8/21/07, Dominique Devienne <dd...@gmail.com> wrote:
> On 8/21/07, peterreilly@apache.org <pe...@apache.org> 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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r568040 - /ant/core/trunk/WHATSNEW
Posted by Dominique Devienne <dd...@gmail.com>.
On 8/21/07, peterreilly@apache.org <pe...@apache.org> 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?
> + 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?
Thanks, --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org