Dominique Devienne wrote:
> 2) DynamicTag is lazy, thanks to UnknownElement. Your rewrite is creating
> the element at parse-time, my implementation does it only at runtime.
> Again, I favor delaying the instantiation and configuration. Ant should
> never have mingled parsing of the XML and instantiation of the model in
> the first place.
+1
ant1.6 is a bit "lazier" than 1.5.
> Something that I wish Ant added was the notion of 'role', to partition the
> task/type namespace. Both our proposals rely on <taskdef>/<typedef> to
> register the extension points. But a custom selector, a custom filter, a
> custom mapper, a custom buildpath (in my case) all share the same type or
> task namespace (the mapping from element name to class name). There are
I wish Ant didn't make the distinction between "task" and "type" so
big. All are "project components" - and the "role" is given by how
they are used. Not having an "execute" method is the only special
thing about a typedef.
> currently two distinct namespaces, one for tasks, and one for types, and
> Costin says I'd like to merge the two, when I actually would prefer to
> have N namespaces, each indexed/keyed by a 'role' string. When a task
Maybe something in the middle :-)
I'm saying that from the point of view of the processor, all components
should be just simple beans, regardless of how they'll be used or
what methods they expose in addition to attributes.
You may have as many roles as you want - at a higher level, by either
implementing some interface or pattern. You may even have components with
multiple roles. As long as at the low level they are all treated as
javabeans ( or ProjectComponents ).
> explicitly declares to accept within it selectors for example, it simply
> declares it wants instances implementing FileSelector.class from the
> "selectors" namespace. So the namespace used to resolve the element name
> to the classname is explicit, rather than implicit, first trying the
> "tasks" namespace, and then trying the "types" namespace. Classes can of
> course belong to more than one namespace; <tahoeresolver> could be both a
> type ("types" namespace), so it can be declared outside <buildpath> and
> refid'd, but it's also a BuildPathResolver.class, of the
> "buildpath/resolvers" user-defined (and documented) namespace).
That shouldn't be a concern of the low-level ant ( the xml parser, etc )
tough. And we shouldn't have one registry for each type.
Costin
