I have done some work on XDoclet 1.2.2 support for Geronimo ( http://xdoclet.sourceforge.net/xdoclet/index.html ).
Where is the work available? Does the URL point to the plugin?
Currently there is support for generating the openejb-jar.xml file for session and message-driven beans (not entity beans).
Hmm, I couldn't find it in the openejb and geronimo repositories. Either I was looking at the wrong places or it's not yet there, which means that to not do the same job twice we have to put what's already done in one of them. I don't even think it's a bad idea to put OpenEJB XDoclet1 plugin in openejb repo whereas Geronimo XDoclet2 plugin would show up in Geronimo repo. Fortunatelly, I have permission to make it happen so once I have finished the work with Geronimo plugin I'll be happy to review the OpenEJB one.
The reasons I chose XDoclet 1.2.2 instead of XDoclet2 ( http://xdoclet.codehaus.org/ )
Is it really worth our time to talk about it? I've always thought that the latest versions/revisions of a project would provide better architecture because the developers would have had more time to think about what's really useful and leave it and throw away the rest. I'll probably see one day if it's a right assumption ;)
* 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.
I don't think it's really an issue. Perhaps, it's similar to an issue J5-over-the-rest-of-JVMs. The user base is also a result of how many projects are based on XDoclet1 or XDoclet2. If we start with XD2 we'll convince people to try out XD2 over XD1, shouldn't we? And finally extend the user base.
* a lack of XDoclet2 documentation
Then it's time to write it ;)
* not many other application servers had XDoclet2 support
Each of them is going to be unique and so is Apache Geronimo. When we use XD2, we'll add another differentiator over the rest of ASes.
* not much activity on the XDoclet2 mailing list archives
Let's then change it. I think Brian Topping can help us with it.
* 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.
Shed some light on the issues and perhaps some subscribers will find yourself to be able to sort them out ;)
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.
What an excellent idea! I'm finishing the review of what's done by Lenming and will commit it to the sandbox. It's up to people who are able to contribute to the project what will be available in Apache Geronimo (think of the time we can spend on both subprojects and if it's really worth our time instead of polishing things that are really required to build the fully J2EE-compliant and certified application server).
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.
Gimme a day or two and the code will show up in sandbox. Then we can extend it to XD1 (again, think if it's worth our time).
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).
+1
John Sisson
Jacek
