Matt Benson wrote:
--- 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.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
