You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by si...@insession.com on 2005/06/29 07:54:26 UTC
Geronimo XDoclet module contribution
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
http://xdoclet.sourceforge.net/xdoclet/maven-plugin.html
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 -
http://xdoclet.sourceforge.net/xdoclet/index.html
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
http://xdoclet.sourceforge.net/xdoclet/tags/apache-tags.html
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.
Re: Geronimo XDoclet module contribution
Posted by Dain Sundstrom <da...@iq80.com>.
+10000
-dain
On Jun 28, 2005, at 11:57 PM, Aaron Mulder wrote:
> 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.
>
> Aaron
>
> On Wed, 29 Jun 2005 sissonj@insession.com 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
>> http://xdoclet.sourceforge.net/xdoclet/maven-plugin.html
>>
>> 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 -
>> http://xdoclet.sourceforge.net/xdoclet/index.html
>>
>> 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
>> http://xdoclet.sourceforge.net/xdoclet/tags/apache-tags.html
>>
>> 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.
>
Re: Geronimo XDoclet module contribution
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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.
Aaron
On Wed, 29 Jun 2005 sissonj@insession.com 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
> http://xdoclet.sourceforge.net/xdoclet/maven-plugin.html
>
> 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 -
> http://xdoclet.sourceforge.net/xdoclet/index.html
>
> 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
> http://xdoclet.sourceforge.net/xdoclet/tags/apache-tags.html
>
> 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.