Hi, Yoikes. Sorry for caving so late ;/
It would have been nice to get some standard system in place before our release but that looks unlikely now - unless you have something up your sleave? On Sun, 28 Apr 2002 23:44, Erik Hatcher wrote: > 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. > > Thoughts? > > However its implemented should be standardized across the three core tasks > we have to keep it simple and common. > > Erik -- Cheers, Peter Donald -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
