From: "Peter Donald" <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
