XDoclet: Attribute-Oriented Programming - XDoclet 2 Design

##### XDoclet

- Overview
- News and Status
- Download/Installation
- Using XDoclet
- Best Practices
- FAQ
- License

##### Ant Task Reference

- <doclet .. />
- <ejbdoclet .. />
- <hibernatedoclet .. />
- <jdodoclet .. />
- <jmxdoclet .. />
- <mockdoclet .. />
- <portletdoclet .. />
- <springdoclet .. />
- <tapestrydoclet .. />
- <webdoclet .. />
- <wseedoclet .. />

##### Tag Reference

- apache (@soap @struts @axis @tapestry)
- bea (@weblogic)
- borland (@bes)
- caucho (@resin)
- ejb (@ejb @dao)
- exolab (@castor)
- hp (@hpas)
- hibernate (@hibernate)
- ibm (@websphere)
- java (@javabean)
- jboss (@jboss)
- jdo (@jdo)
- jmx (@jmx)
- jsf (@jsf)
- macromedia (@jrun)
- mockobjects (@mock)
- mvcsoft (@mvcsoft)
- mx4j (@mx4j)
- objectweb (@jonas)
- oracle (@oc4j)
- orion (@orion)
- portlet (@portlet)
- pramati (@pramati)
- spring (@spring)
- sun (@sunone)
- sybase (@easerver)
- tjdo (@tjdo)
- web (@web @jsp)
- webwork (@webwork)
- wsee (@wsee)
- xdoclet (@xdoclet @doc @msg)

##### Feature Documentation

- Using Value Objects
- EJB Environment Handling

##### Advanced

- Maven Plug-in
- Merge Points
- IDE Integration
- Migration from EJBDoclet
- Ant 1.5 Troubleshooting

##### Community

- Feedback
- Resources
- Tools

##### Development

- Developer Guide
- Javadoc (API)
- Template Language (*.xdt)
- XJavaDoc Site

##### Search XDoclet

##### Project Documentation

- About XDoclet
- Project Info
- Project Reports
- Development Process

## XDoclet 2 Design

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.

### Goals

General:

- Major performance improvements
- Simple API for writing plug-ins (less bound to the core)
- Unit tests, unit tests, unit tests. Did I mention unit tests?
- Use Jelly for generation of XML, Velocity for generation of Java and other miscellaneous files.
- Tag validation and warnings about missing or incorrect tags

Standards support:

- EJB 2.1
- Servlet 2.4 and JSP 2.0

EJB-JAR Plug-in:

- New tag (supported in multiple plug-ins): @ejb.bean read-only="true"
- getValue() and setValue() are generated in the CMP class when @ejb.value-object is used
- @ejb.value-object name="..." is optional (defaults to @ejb.bean name="..." + "Value")

Build process:

- Build process fully integrated with Maven
- Use XDoclet without Ant
- CruiseControl or AntHill for continuous integration and hourly builds.

Plug-ins:

- Maven Plug-in
- Eclipse Plug-in
- IDEA Plug-in

Generated sources:

- Generation of a Session Facade
- Generation of a Message Facade
- Generation of JUnit Tests and Mock objects
- Generation of Business Delegates

Documentation:

- Full merge point documentation
- Improved Tag Reference
- UML documentation
- XDoclet 1.2 to 2.0 Migration guide

### Deprecated and Removed

- NO more support for EJB 1.0 and 1.1, use XDoclet 1.2 for this
- NO more support for HPAS (HP discontinued it)
- @ejb.aggregate is removed in favor of @ejb.value-object
- @ejb.data-object is removed in favor of @ejb.value-object
- @ejb.persistent-field is deprecated in favor of @ejb.persistence (a warning is printed to the console)
- @ejb.use-soft-locking is removed (was only valid for EJB 1.0 and 1.1 beans)
- All deprecated methods in XDoclet 1.2 are now removed

### Template System

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.

### XRAI

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?