If I might add a few points of note...
* X2, based on QDox, is solidly an order of magnitude faster than X1.
* I'm currently using both X1 and X2 at the same time on several projects. The dependency load on X2 is very light, so there's not a significant cost for this, especially in light of the last point.
* The ease of developing a plugin using the raw facilities (which is about all you have with X1 anyway) is much easier because you have Velocity, Jelly, and Freemarker ready to work with. * X2 uses Picocontainer, a constructor-injected IOC container, which has a programming style very similar to the manner that Geronimo has been built. If you want to get eager developers stared with ctor-IOC, pushing them to start with writing plugins is a great way to go.
There's a few other issues that would lend encouragement to using X2 instead of X1, but I'll only mention one, and that is that we are committed to helping people get going with X2 on IRC, which Len can attest to.
In the face of J5 annotations, both of the XDoclet generations have a limited life expectancy if taken at face value, and it might seem rather myopic to be putting any effort into XDoclet at all. But the Dentaku project has successfully adapted X2 around a UML metadata source such that plugins written for X2 can be adapted without recompilation (by driving the QDox builder methods) to generate configuration files from UML models. People either love or hate UML, but it's hard to argue that something for nothing is a bad thing, and model-driven architecture is just starting to heat up. Having MDA support for large enterprise is going to be a big plus.
Throughout this, J5 APT will grow, but will never be able to catch up fully because the richness of metadata from doclet tags and static structural notations is no match for MOF-based metadata, which can embody behavioral and structural notations.
As far as new development, I am currently writing an AST-based generator (thanks Jeremy ;) that can take a XML Schema and some hints and turn out a fully validating plugin. It's very easy to transform a DTD into a Schema, so there's no concern about not having a schema handy to generate against. And as this work progresses, I believe it will be a very quick way to cross-check your Schema to see if you have properly bounded elements and attributes (since the generator may have a tough time with poorly developed Schemas). I hope to see the generation of complex plugins turn into efforts measured in days instead of similar numbers of weeks and eliminate out of date cartridges in the process.
Is there anything I can do to help demonstrate to you that X2-only is the better way to go here? It's absolutely true that X1 has a very strong set of plugins, but if you look more closely, many of them are out of date because X1 templates are so difficult to maintain. This isn't going to get better over time, and the reason X2 is weak right now is that no recent effort has been made to champion it.
Do what you think is right, but X2 use and support is gaining momentum, not losing it. It would be great to have everyone on board that we can. Please feel free to come by irc.codehaus.org on #generama if you would like.
(Merry Christmas to everyone... :-)
-b
[EMAIL PROTECTED] wrote:
I have done some work on XDoclet 1.2.2 support for Geronimo ( http://xdoclet.sourceforge.net/xdoclet/index.html ).
Currently there is support for generating the openejb-jar.xml file for session and message-driven beans (not entity beans).
The reasons I chose XDoclet 1.2.2 instead of XDoclet2 ( http://xdoclet.codehaus.org/ ):
* it appears to have a larger user base, is already used by many projects and the supports the majority of other application servers. Adding Geronimo support to a future XDoclet 1.2.* distribution would expose Geronimo to that user base and hopefully encourage its adoption.
* a lack of XDoclet2 documentation
* not many other application servers had XDoclet2 support
* not much activity on the XDoclet2 mailing list archives
* I have limited time to get some existing projects (that use XDoclet for generating App Server specific deployment descriptors for various App Servers) to be able to generate Geronimo deployment descriptors/plans.
I'm not suggesting XDoclet2 is not the way forward and my decision was based upon nontechnical observations. It would be nice if we could provide both XDoclet 1.2.2 and XDoclet2 support, so the user has the choice of what they want to use. If we are going to do that, we would want to ensure that the @Geronimo tags are consistent between the two, so people can move from one to the other as easily as possible.
The tags supported in Len Yeung's XDoclet2 support ( http://nagoya.apache.org/jira/browse/GERONIMO-519 ) don't appear to overlap the tags supported in my XDoclet 1.2.2 support, so we have time to get this right.
I am currently working on basic tag reference doco (the xtags.xml file) and once complete, will create another JIRA issue and attach patches so people can review and contribute. Once Geronimo's configuration has stabilised we could then look at moving the Geronimo XDoclet 1.2.2 module source to the sourceforge project so that it is included in future XDoclet releases (assuming there aren't any licensing issues preventing that).
Regards,
John Sisson
