ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition: ConditionBase.java antlib.xml
Date Fri, 01 Sep 2006 14:47:03 GMT
--- Steve Loughran <stevel@apache.org> wrote:

> mbenson@apache.org wrote:
> > Author: mbenson
> > Date: Thu Aug 31 12:04:12 2006
> > New Revision: 439014
> > 
> > URL:
> http://svn.apache.org/viewvc?rev=439014&view=rev
> > Log:
> > Auto-discover built-in conditions added >= 1.7
> from the accompanying antlib so we can stop adding
> junk setters to ConditionBase.
> > 
> 
> > +
> > +    /**
> > +     * Create a dynamically discovered condition.
>  Built-in conditions can
> > +     * be discovered from the
> org.apache.tools.ant.taskdefs.condition
> > +     * antlib.
> > +     * @param name the condition to create.
> > +     */
> > +    public Object createDynamicElement(String
> name) {
> > +        Object cond =
> ComponentHelper.getComponentHelper(getProject())
> > +            .createComponent(CONDITION_ANTLIB +
> name);
> > +        if (!(cond instanceof Condition)) {
> > +            return null;
> > +        }
> > +        log("Dynamically discovered '" + name +
> "' " + cond,
> > +            Project.MSG_DEBUG);
> > +        add((Condition) cond);
> > +        return cond;
> > +    }
> > +
> >  }
> > 
> 
> hmm. What happens to third party tasks that extend
> this and already have 
> dynamic binding stuff built in. I dont know of any,
> though I've done two 
> extensions myself, <failingwaitfor> and some little
> toy one to count 
> conditions for the book
> 

My expectation is that Dynamic(Element|Attribute)(NS)?
have not been publicized to the point that any
ConditionBase extension implementing DynamicElement is
likely to exist in the wild.  Anyone who has bred such
a beast is with around 99% certainty subscribed to
this list, and if so, he hasn't spoken up yet.  Still,
if this change stands, it could technically be
categorized as a possible breaker in WHATSNEW.  Again,
while this is theoretically possible, I would not just
be surprised--I would be shocked--if anyone not
subscribed to dev@ant.ao were bitten by this.

> 
> package org.antbook.conditions;
> 
> import
>
org.apache.tools.ant.taskdefs.condition.ConditionBase;
> import
> org.apache.tools.ant.taskdefs.condition.Condition;
> import java.util.Enumeration;
> 
> public class CountConditions extends ConditionBase {
> 
>      public void execute() {
>          int passes=0;
>          int failures=0;
>          Enumeration conditions = getConditions();
>          while (conditions.hasMoreElements()) {
>              Condition c = (Condition)
> conditions.nextElement();
>              boolean pass=c.eval();
>              if(pass) {
>                  passes++;
>              } else {
>                  failures++;
>              }
>          }
>          log("Conditions passing: "+passes+"
> failing: "+failures);
>      }
> }
> 
> Personally, I'd like add(Condition) just to work :)
> 

As Peter said, just "def"ing new conditions should be
a viable alternative.  The likely sources of
collision--and/or/not/etc--are already accounted for
with setters.  Before, I mentioned that some committer
had written in oata.types/defaults.properties:

please add new conditions to
oata.types.conditions/antlib.xml instead of
here, to avoid namespace clash with things like
selectors.

I suspected, but did not bother to check, who that
committer was yesterday.  Today I checked and found my
suspicions were correct.  It was you, Steve!  :)  So
do you recall your train of thought when you added
this admonition to the properties file?  Do you
retract that opinion; shall we doubly define
non-colliding conditions in the antlib as well as
oata.types/defaults.properties?

-Matt

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



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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


Mime
View raw message