Looks like this chain got out of hand and killed the discussion. But we need consensus here on what to do before 1.7 final ships. Background: My assertion is that we should no longer allow the proliferation of addNewConditionOfTheWeek() methods on ConditionBase; my (unorthodox as usual) solution was to allow business as usual in ConditionBase first: check for explicitly named addFoo() methods, then check for def'd conditions with add(Condition). The modification is to then implement DynamicElement in ConditionBase so that when the first two introspection methods fail; ConditionBase's DynamicElement implementation searches for a matching condition by prepending the antlib:org.apache.tools.ant.taskdefs.condition ns to the element name and searching the Project's ComponentHelper for the corresponding definition.
Reactions were varied. Antoine thought it sounded cool (Thanks!). Peter didn't like it and suggested we simply define all new/non-colliding conditions. Steve voiced concern wrt third-party ConditionBase extensions already implementing DynamicElement but conceded (IIUC) that risk was low. Surprisingly, DD, who is often more frightened by my solutions than Peter, had no comment. ;) Peter's suggestion to define as many conditions as we can competes with an earlier imperative to add new conditions only to the new condition antlib mentioned above. I have attempted (with dubious success) to edit down the thread, since the last activity on the thread was my (sadly, ignored) response to Steve: ;) (RE this warning 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. > > > > > (Me to Steve:) > > > 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? ( > > = Steve. > = Me: ) > > 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. > > But with taskadapters, can't any class with an > execute() method function as a task? As does > <condition>? > > > 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: > > > > Are you saying that the smartfrog stuff uses Ant > tasks, but needs true tasks? Hmm. > > > > 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. > > > > So what does all this mean for the issue at hand? > :) > > -Matt > > > -steve __________________________________________________ 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]
