ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <jakarta-...@ehatchersolutions.com>
Subject Re: IntrospectionHelper request
Date Thu, 10 Jan 2002 12:10:55 GMT
From: "Peter Donald" <peter@apache.org>

> 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/EjbJar.java.
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="newejb.properties"
newejb.properties 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:
<http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xdoclet/core/src/xdo
clet/ejb/EjbDocletTask.java?annotate=1.25>  (sorry if the URL wraps and
breaks)

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

Seem reasonable?

    Erik



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message