ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: IntrospectionHelper request
Date Thu, 10 Jan 2002 12:43:45 GMT
On Thu, 10 Jan 2002 23:10, Erik Hatcher wrote:
> Have a look at org/apache/tools/ant/taskdefs/optional/ejb/
> Notice that it createIplanet, createWeblogic, createWebsphere, etc.  Thats
> got zero extensibility to plug in a new vendor.  By adding a dynamic lookup
> of EJBDeploymentTool implementing classes all that vendor-specific stuff
> could be pulled into a properties file embedded in the Ant distribution for
> the Ant provided ones, and then dynamically add them by having some kind of
> add-on lookup.... plugins=""
> has newvendor=com.newvendor.OurDeploymentTool and then
> <ejbjar> could use <newvendor> (the properties lookup is just my
> home-brewed idea, and isn't the only way or the best way)

Im not disgreeing with the need but as I said I disagree with the method and 
consider it a workaround for limitations in Ant1.x model. The 
lookup/registry/factory etc for new implementations of interfaces should NOT 
be done by the task but should be done by the container.

> So, which is uglier?  Lack of extensibility in the current hard-coded way
> of having sub-elements for tasks?  Or the DynamicConfigurator way of
> allowing pluggable sub-elements and attributes?

Both are equally ugly IMHO. I would prefer the approach I have outlined in 
the other threads ;)

> Are those use-cases enough?  :)

They are workarounds for ant1.x failings and thus I don't consider them valid 
usecases at all ;)

> As for dynamic attributes, the same kind of stuff applies, but more
> specifically I'm working on a custom task (soon to be seen by Jakarta) that
> has an attribute to specify a 'handler' class,
> handler="com.whatever.MyHandler".  I want to be able to pass configuration
> data to a handler, and via a Map would be best (or Properties).  It would
> be nicer to say:
>    <mytask prop1="some stuff" prop2="some more stuff">
> rather than
>    <mytask>
>       <data name="prop1" value="some stuff"> .....
> Seem reasonable?

no ;)



PROGRAM: n.  a magic spell cast over a computer allowing it to turn
one's input into error messages.  v.t.  to engage in a pastime similar
to banging one's head against a wall, but with fewer opportunities for 

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

View raw message