Arguing XDoclet.
People seem to understand the need for XDoclet code generation in the EJB world where there is a lot of boiler plate code and lots of ugly deployment descriptors to be written, but I've had a harder time convincing people to use XDoclet to generate web.xml, tag library descriptors, and Struts configs.
My coworkers understand the Servlet specification and they know the details of the web.xml DTD, so they see XDoclet as just another quirky tool to be learned. It seems to get in the way, it has bugs, and it is not always updated quickly enough for folks want to use the latest stuff (Servlets 2.4 for example). Learning to use the XDoclet tags is not all that difficult, the open source allows capable programmers to make bug and enhancements, but this is not very reassuring to folks who just want to add another Filter Mapping to web.xml, right now, damnit.
I've gone a couple of rounds with folks discussing pros and cons and I forgot the most obvious argument - continuous integration. The best reason to use a tool like XDoclet to generate web.xml, tag library descriptors, Struts configs, and other goodies is refactoring. If you have a bunch of Servlets, JSP Tags, and Struts Action classes in your code and you want to refactor your code by renaming classes and moving them between packages then you will have to carefully edit web.xml, your TLDs, and your struts-config.xml to correct all of the changed class and package names. If you were using the XDoclet @servlet, @jsp.tag, and @struts.action tags you would have no worries - all of your deployment files would be auto-magically updated.
It's common that you'll find somebody using XDoclet to help build their EJBs, but how often do you find people using it to help with the J2EE web tier?
Posted by Simon Brown's weblog on October 16, 2003 at 09:23 AM EDT #