ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Generic Element Containers (generalization of TaskContainer)
Date Fri, 30 Nov 2001 14:57:14 GMT
Stefan point about making <fail/> contain conditions brings back something
I have been thinking about for a while.

Today, we have special treatment of TaskContainer which allows a task
to declare that any task (or DataType) can be defined as nested elements.

But more and more we have other Tasks that can be containers for some particular
subset of elements. The typical example is <condition>. Today the way we deal
with this is to add new methods to <condition> every time we define a new
<conditional> quite unmanageable when we keep on adding more and more
conditions, almost unmannageable now that we may have two or three different
containers, and really unmanageable if we ever provide pluggable user defined 

The same occurs for <mappers> <cullers>, etc. Specifying implementation class
names looks really awfull.

Can we come-up with a way to generalize what we do for TaskContainer?
If we provide a way for the Container to indicate which king of thing it can contain
then the problem could be solved. Some possible approaches would be:

    interface ElementContainer {
        String getElementsCathegory() // The name of the cathegory in which to search
        void addElement(Object element)

So rather than having seratetly managed hashtables for different things we could have
one unified symbol table controlled by ANT in which things are registered by cathegory:
task, condition, datatype, culler, mapper, etc.

When you decare an object to ANT, like with my infamous <antlib/> you specify
onder which cathegory(ies) you want it declared:

        <element name="echo" 
                        cathegory="task" />
        <element name="glob"
                        cathegory="mapper" />

I think this would provide a quite extensible, easy to manage and consistent mechanism.

And yes, there should be no problem on keeping backward compatibility.


Jose Alberto

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message