ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: IntrospectionHelper request
Date Thu, 10 Jan 2002 12:10:55 GMT
From: "Peter Donald" <>

> implementation is fine and yay you used an interface - everyone else here
> seems to prefer reflection.


Don't hold it against me, but I used the interface that Jose provided - my
original thoughts were just for attributes, but the elements really adds
life to it.

> > Peter - thoughts?  What kind of potential beasts are we unleashing if we
> > accept this?
> a whole bunch of uglies ;)

Ok, see below for all the uglies that it could remove....

> Well the negative is mainly that as yet you haven't been able to give me a
> real use case. It wouldn't even help in the case of the DocletInfo or
> whatever it was due to the way javadoc works and besides I consider it a
> workaround for the limitations of Ant1.x rather than a good features.
> So probably the best idea is to come up with a valid use case :)

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)

Now, look at the same situation on the XDoclet side of things:
clet/ejb/>  (sorry if the URL wraps and

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?

Are those use-cases enough?  :)

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
      <data name="prop1" value="some stuff"> .....

Seem reasonable?


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

View raw message