On 9/11/06, Matt Benson <[EMAIL PROTECTED]> wrote:
--- Dominique Devienne <[EMAIL PROTECTED]> wrote: > > >> However, it is a pity that AssetTask has to > extend > > >> ConditionBase ... oh well. > > > > > > It doesn't "have to", does it? All it needs is > an add(Condition) > > > method, no? > > > > No. Most of the "old" conditions are not > <typedef>ed and so don't > > have a "name" of their own, you can't add them to > a task that only has > > add(Condition). > > What is preventing us from declaring them? OK, > typedef'ing them would > probably create some havoc and name conflict. > > Now that we have add(Type) introspection (what I > also call extension > points), we should *really* get away from being > forced to derive from > ConditionBase or similar base classes. I see two > ways to allow this: > > 1) Have an Ant-conditions antlib, and force users of > AntUnit to > explicit load it, with or without using an XML > namespace. I'd be fine > with this myself. Steve introduced said antlib in the 1.7 codebase.
it is in antlib:org.apache.tools.ant.taskdefs.condition (possibly should be in o.a.t.a.types.condition !)
> 2) Introduce a <tagdef> or <roledef> for the purpose > of locating > extension points as nested elements. They differ > from <typedef>s in > that they don't allow to declare these 'tags' at the > top-level, but > only as nested-elements of another type or task. > This is interesting but quite possibly too complicated to make 1.7 .
I had (have if I can find it) some code in IH (IntrospectionHelper) to do this but I looked at the code and realized that the type handling in ant would become too complicated - there would be a number of classes corresponding to the name "x" and at runtime, ant (IH) would pick the "best" one depending on the class that corresponded to the container element. I realized that this would not be general/usefull enough for third party antlib libraries - it would rare that the same name woud be used for multiple contexts and the current simple name -> class mapping is sufficient. Therefore the only use for the complicted type lookup would be for core-ant names that map to multiple ant classes depending on the role - "or", "and" "xor", and a small number of others. 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 . Peter
In any event, there are similarities here with my recent change to ConditionBase to implement DynamicElement and look up unknown elements in the aforementioned antlib. We actually need to finish that conversation on-list before 1.7 final as well; I'll ping that thread. :)
-Matt
> What do you think? --DD > > --------------------------------------------------------------------- > 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]
