Re: DynamicConfigurator-Interface

[Erik Hatcher]

Unfortunately it was added too late before the 1.5 feature cutoff to 
have any implementation within Ant's own codebase.  But XDoclet uses 
it, which allows for an extensible task facade for XDoclet's subtasks.  
A vendor could now write their own XDoclet module and simply dropping 
the JAR within the <taskdef> classpath the subtask becomes available... 
e.g.

        <ejbdoclet...>
       <someNewVendorSubTask..../>
   </ejbdoclet>
The <ejbdoclet> task implements DynamicConfigurator.  Before this 
addition, <ejbdoclet> would have to be hardcoded with a 
createSomeNewVendorSubTask (or add/addConfigured) method making it very 
rigid.

Ant's <ejbjar> task is a perfect candidate for this refactoring also.  
The tough part is coming up with the discovery mechanism.  The XDoclet 
team has a slick way of doing this by looking for XML descriptor files 
in the classpath, and plugin modules simply have to embed that within 
their JAR.

The same dynamic nature can be done with attributes, so setters for 
every attribute are not needed.

        <someTask attribute1="..." attribute2="...." ..../>
With no fixed setters for those attributes.  Perfect for the extended 
JDBC attributes, it seems, although a nested <attribute> element could 
be made to do a similar dynamic feature too.  It seems cleaner to 
express things with attributes with meaningful names though.

        Erik
On Tuesday, January 21, 2003, at 09:12  AM, [EMAIL PROTECTED] 
wrote:
When should I use that interface? I had a look at it (and the only
implementing class
I found was XSLTProcess.Factory.Attribute). I don´t see any requirement
for the Attribute-Class to implement that interface. So I ask myself - 
why
to implement it?

Jan Matèrne

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>