geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Topping <topp...@codehaus.org>
Subject Re: XDoclet 1.2.2 support for Geronimo ( different to XDoclet2 support in GERONIMO-519 )
Date Sat, 25 Dec 2004 05:12:43 GMT
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

sissonj@insession.com 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
>
>
>  
>

Mime
View raw message