--- Steve Loughran <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
