geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Geronimo XDoclet module contribution
Date Wed, 29 Jun 2005 06:57:45 GMT
	I vote we maintain it in Geronimo at least until it's stable.  Can 
we give XDoclet a "current JAR" for them to incorporate into their build, 
or will they only incorporate things into their build if they own the 
source for that thing?  If they insist on owning the code, perhaps it 
could be migrated to them once stabilized.

	Of all the things you listed, improving schema documentation 
jumped out at me since it's valuable and can be done independently of any 
XDoclet code.


On Wed, 29 Jun 2005 wrote:
> Aarons "So I'm working on..." mail prompted me to get this discussion 
> going..
> In December 2004 I did done some work on XDoclet 1.2.2 support for 
> Geronimo EJBs but did not get around to contributing it.  Currently it 
> supports the generation of the openejb-jar.xml file for session and 
> message-driven beans.
> I would like to discuss where the most appropriate place to contribute the 
> Geronimo XDoclet plugin code would be.
> Should we:
> 1. Maintain & Develop the it under the Geronimo project (incorporating it 
> into the Geronimo build process).
> Benefits: The XDoclet support is maintained by the Geronimo developers and 
> is kept in sync with Geronimo.  Possibility to respond quicker to bugs - 
> users don't have to wait for the next XDoclet release to include the bug 
> fixes.  Could use Maven to download XDoclet and the appropriate version of 
> the Geronimo plug-in 
> Disadvantages: The development of XDoclet v1.x modules is usually done 
> under the XDoclet project and when a version of XDoclet is released, it 
> includes modules for the different app servers.  This would mean if a user 
> grabbed the next version of XDoclet v1.x it would not automatically 
> include support for Geronimo.  For example, for an Xdoclet 1.2.3 release, 
> the user would have to copy the file xdoclet-geronimo-1.2.3.jar to their 
> XDoclet lib directory. 
> 2.  Maintain & Develop it under the XDoclet project - 
> Benefits: The Geronimo module would automatically be included in future 
> versions of XDoclet and its documentation would be shown on the XDoclet 
> web site.  Note: there is a bunch of modules (@soap, @struts, @axis, 
> @tapestry) grouped under "apache" on the XDoclet site 
> Disadvantages: Higher chance that the XDoclet module won't be maintained 
> properly (e.g. Geronimo is enhanced, but nobody remembers to add support 
> for the enhancement to the XDoclet plug-in).  Not possible to have 
> multiple versions of the Geronimo XDoclet module (e.g. a version for each 
> milestone build or release of Geronimo).  This does not sound practical 
> considering Geronimo's configuration has not yet stabilised and is likely 
> to evolve further.  Unknown schedule for XDoclet releases.
> Further work required
> ==================
> the following contributions/help by others are welcome :-) :
> - Incorporate support for recent additions to Geronimo's configuration xsd 
> files.
> - Improvements to the Geronimo XDoclet tag documentation
> - web support
> - entity beans support
> - GBeans support
> - Testing with XDoclet support in Eclipse WTP and other IDEs
> - Improving the documentation in Geronimo's xsd configuration files to aid 
> users diagnosing problems.
> John
> This e-mail message and any attachments may contain confidential, 
> proprietary or non-public information.  This information is intended 
> solely for the designated recipient(s).  If an addressing or transmission 
> error has misdirected this e-mail, please notify the sender immediately 
> and destroy this e-mail.  Any review, dissemination, use or reliance upon 
> this information by unintended recipients is prohibited.  Any opinions 
> expressed in this e-mail are those of the author personally.

View raw message