ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject DynamicConfigurator discussion
Date Sun, 28 Apr 2002 13:44:05 GMT
Now that Peter has graciously allowed the DynamicConfigurator interface into
Ant 1.5, its down to the wire to get it utilized in the tasks that so
desperately need it - <ejbjar>, <serverdeploy>, and <condition>.

The question I have is: what do you think is the best way to go about
implementing it in those tasks?

Suppose an EJB container vendor wants to plug-in their own
EJBDeploymentTool - how would they go about doing?

A couple of ideas:

    - Create a new datatype (similar to XMLCatalog in that it has all the
classpath setting stuff) that allows you to specify name/classname pairs and
can handle the same <taskdef> stuff with resource/file attributes. <ejbjar>
would then have a 'pluginref' attribute added and use that info in the
createDynamicElement method.  The drawback is that this requires build file
modification by the user to add a vendor - which is not that big of a deal
with the file/resource attributes though.

    - Use System or "magic" properties (perhaps using the same standard?
mechanism that ProjectHelper uses to look up its implementation) so that
'ant.ejbjar.<element name>.classname=com.<vendor>.SomeEJBDeploymentToolImpl'
is set externally - this would allow IDE's to automatically supply such
settings. Someone will still have to have these properties set, but it could
be controlled externally.

I don't want to do anything dramatic or wrong, so if having this supported
in our own tasks doesn't happen in Ant 1.5 thats cool.  XDoclet will benefit
dramatically from DynamicConfigurator, and that is enough of a benefit to
make it worthwhile already.  They implement a 'deployment descriptor' system
where an XML file is embedded in the META-INF tree of the JAR files and is
used to map classname to element-name by task classname.


However its implemented should be standardized across the three core tasks
we have to keep it simple and common.


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

View raw message