THIS DOCUMENT IS OBSOLETE; FOR MORE INFORMATION ON XDOCLET2, CHECK http://xdoclet.codehaus.org.
This document is a proposal for the XDoclet 2 design. This version is a complete rewrite and will probably break compatibility with older versions and source files using wrongly formatted tags.
Please take note that modules are now named plug-ins.
For more up-to-date details about the new XDoclet 2 architecture, check out the xdoclet2 CVS module.
General:
XDoclet is validly criticized for its template system. Unfortunately there were neither Velocity nor Jelly available in that old times when I was finalizing the template system. Velocity was still a v0.4. So the very tag- is but simple template system was born. It served pretty well but now that the templates are becoming more and more complex it proves to be the Achilles heel of XDoclet. So we're throwing it away in 2.0 and introducing a new Template Abstraction Layer, so you'll be able to write the templates in Velocity or Jelly or whatever.
Fascinating idea from Ara. You might already know that .Net provides a runtime-based system for accessing attributes (@tags), so you can simply do something like anobj.getClass().getAttribute("ejb.bean") for example, whereas in java you read an xml file, and XDoclet is a compile time system which reads attributes. JSR 175 works on a runtime system, but for now what do you think about a simple simulation of a runtime attribute access API? So the idea behind XRAI is a post-proccessor ant task which reads source code and modifies the compiled classes with BCEL and injects some static fields to classes. It injects things like private static final Attribute[] attributes = new Attribute[]{new Attribute("ejb.bean", ...)} and with a naming convention for method level tags too. You'll be able to access the tags with an API like this: AClass.getAttribute("ejb.bean"). Ideas?