User Documentation

One Minute Introduction

Two Minute Introduction

Your own plugin

Coffee Break Introduction

Property substitution

FAQ

IDE Integration

Doclipse

Maven Integration

Maven2 Plugin

Maven1 Plugin

Plugins

• Actionscript plugin
• Beaninfo plugin
• Castor plugin
• Ejb plugin
• Externalizer plugin
• Hibernate plugin
• Interfaceextractor plugin
• Jdo plugin
• Jmx plugin
• Junit plugin
• Plugin plugin
• Portlet plugin
• Qtags plugin
• Spring plugin
• Struts plugin
• Tapestry plugin
• Web plugin
• Webwork plugin
• Xtags plugin
• Xwork plugin

Project Information

Mailing lists

Source Repositories

Open Issues

Team

Developer Documentation

Feeds

• Site
• News

Does Java 5 Annotations mean 'beginning of the end' for XDoclet? //TODO

It probably would not be way off the mark to say that XDoclet inspired the introduction of the new Annotations feature in Java5. Metadata, currently specified as QDox tags, can be specified through Java5 annotations. It might lead us to conclude that this renders XDoclet obsolete. It is indeed true that newer frameworks will read and apply their respective services at runtime on code artifacts that carry a specific annotation. Popular open source projects like Hibernate 3.x, Tapestry 4.x have already adopted annotations to describe metadata thereby eliminating the need for configuration files for storing the same. But then XDoclet is a Code Generation tool. As long as there is a need for code generation, XDoclet should still make sense. We saw that a nice abstraction has been built on top of the metadata source. (I believe, its not there yet!). Generama can just as well replace QDox with an equivalent parser that reads 'annotated' Java5 source files. It appears the codehaus already has JAM (http://annogen.codehaus.org/JAM) to do that. Either way, the Tiger release has already addressed this through Java5 Annotation Processing Tool.

XDoclet2 Vs APT (Java 5 Annotation Processing Tool) //TODO

Java5 comes bundled with Annotation Processing Tool (APT), a command line tool, to process the source level annotations at build time. It also provides a reflective api that models the java's type system.

(Now I'm not quite sure if this section should be titled 'XDoclet 2 Vs APT'! since apt and the associated reflective api seems to resemble QDox. Now that I'm done with initial investigation of APT, need to develop! and then figure a way to register a simple 'APTMetaDataProvider' with Generama. And now I really am not sure how to adapt this to Generama's MetadataProvider interface! (I mean the QDox dependency). How about QDox tag validation. How to tie that to APT? Java5 provides meta annotations types and as the name indicates, are used to annotate annotations. It lends the ability to specify the location of annotations in the source file for eg, thereby some form of valdiation. APT is not Generama, in the sense that it does not, by itself, allow for pluggable templating engines. APT mirrors the java type system through interfaces. They reside under the sun packages. So even though it is fully developed, it is likely to change. Work is currently in progress on standardizing the api.