ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: polymorphic data types as nested elements
Date Thu, 22 Aug 2002 10:16:11 GMT
Shackelford, John-Mason wrote:
> I am rewriting the PVCS task. The top level task is a command processor that
> does not know anything about the commands it executes other than that they
> conform to the PCLICommand interface (abstractly implemented by
> AbstractCommand which subclasses DataType). Specific commands, Get for
> instance, subclass AbstractCommand. 

Have you had a look at the other SCM tasks in the Ant codebase? 
Clearcase and VSS, for example (and I'm sure others), have a base Task 
class that they extend.  So your pattern is a worthy improvement over 
this, but a bit similar as well.

> <typedef name="get" classname=""/>
> <typedef name="command" classname=""/>

I'm with Dominique here - why have DataType's in the equation?  Do you 
plan on reusing them across multiple <pcli> invocations?  If not, then 
its way overkill.

> Since I don't want my PCLI class to know anything about the concrete command
> classes, I use the DynamicConfigurator to instantiate the appropriate
> command based on element name.
>     public Object createDynamicElement(String name) throws BuildException {
>         String dataTypeFQN = (String)
> getProject().getDataTypeDefinitions().get(name);

So, you're using datatypes simply to have a mapping of name/classname. 
I'd recommend you use some other design for this if this is the only 
reason your using datatypes.  Look at XDoclet's CVS codebase and how 
they have an XML descriptor in their META-INF folder of their JAR files 
that provides the lookups.

But regardless - you're definitely on a good track here.

>         //  make sure we have a command object
>         if (!(obj instanceof PCLICommand))
>             throw new BuildException(
>                 "Element " + name + " is not a PCLI command and cannot be
> executed.");
>         return obj;
>     }

Groovy.  You've got this part going nicely, and using the datatype thing 
is an interesting hack to get the lookups working.  Ingenious, in fact. 
  But I still think its overloading and (ab)using (to borrow from 
Dominique!) what a DataType is - unless of course you have plans for 
reusability here somehow.


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

View raw message