> > 2) Introduce a <tagdef> or <roledef> for the purpose > > of locating extension points as nested elements.
but I looked at the code and realized that the type handling in ant would become too complicated - there
I see your point. Increased complexity is not good. But is it really that complex? This new mechanism would only kick in when IH would overwise have rejected a nested element, and only add lookup into a new mapping when the current type has an add(Type) extension point. True, their can be tricky cases when a type has both an add(Condition) and a add(FileSelector), but that should be pretty rare, and could be thrown out as ambiguous. It could even be resolved using the undocumented ant:type attribute.
It would however be nice to get something that allows add(Condition) or add(FileSelector) to work without having to extend BaseCondition or whatever is done for FileSelector .
Precisely. Unless I'm mistaken, this can already be achieved now by using namespaces, and the condition antlib. So AssertTask could be made ConditionBase independent now, no? --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
