ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
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 15:20:26 GMT
Matt Benson wrote:
> --- 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.


I'd expect cactus and ant-contrib to be the only other projects that 
extend these things, but they should be warned.

> 
> 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?
> 

I think Stefan told me off :)

Here's the problem

-ant's core conditions are not defined as types
-third party classes cannot go add(Condition) and get all conditions
-I stuck the antlib in to make it possible, but dont think we have any 
tests for it being included in the JAR
-If you do make them a type, there is the problem that a <contains> 
selector already exists, and now we have a <contains> test.

To make things more entertaining, if you do extend ConditionBase, you 
don't have a task. This really annoyed julio, when he was adding the 
smartfrog component for ant (the one that lets you use ant stuff in a 
smartfrog descriptor, as opposed to the ant tasks for smartfrog).

I had fun in FaultingWaitFor, where I had to reimplement waitfor as a 
task. I cannot get at any of the ant1.7 stuff unless it is defined as a 
condition, because my code needs to build on ant1.6:

http://smartfrog.cvs.sourceforge.net/smartfrog/core/extras/ant/src/org/smartfrog/tools/ant/FaultingWaitForTask.java?view=markup

To make things more complex, this task gets nested in a <functionaltest> 
task that has a setup, probe, test and application in parallel and a 
finally sequence that runs after the tests. It has  an order like

            setup
         /               \
   application   probe (until probe passes or timeout)
          |           test
          |          finally
          \           /
        finished

We use it for functional testing, obviously.

http://smartfrog.cvs.sourceforge.net/smartfrog/core/extras/ant/src/org/smartfrog/tools/ant/FunctionalTestTask.java?view=markup

DynamicElement has been round since 1.5; the NS is more recent, and I 
dont go near it myself.

-steve


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


Mime
View raw message