"Craig R. McClanahan" <[EMAIL PROTECTED]> writes:
> Therefore, I'm great with adding some additional committers and starting
> work on the TODO list in the 1.1 tree. I've also asked Ted Husted to
> create a "contrib" directory at the top-level (in the 1.1 branch) and
> manage the posting of other contributions that have not yet been
> integrated into the Struts main codebase. (If there is a high volume of
> this, we might want to create a "jakarta-struts-sandbox" repository for
> such things, analogous to what several other Jakarta projects have done.
Ted Husted <[EMAIL PROTECTED]> writes:
> You can send it to me, Francois. I'll post it on my Struts page right
> away, and add it to the Contributor's area in the Struts CVS later this
> week.
Great !
I really like the idea of a contrib area in struts as well as a the
suggestion of a sandbox repository. As you might have noticed, I
spent already some thoughts about a walkable way of integrating user
contributions to struts. (I came up with strutsx.org. This was
probably not a very good idea according to the zero resonance)
I would like to start a discussion about the structure about such a
contribution area. What can be done to make it as painless as possible
for the maintainers to integrate a new contribution ? How can some
minimal quality standards be guaranteed ? What are the requirements
for a user contribution ?
To support these goals, I have the following suggestions:
* contributions are stored below
$STRUTS/contrib/<user id>/<contribution id>
* A directory hierarchy is suggested,e.g.:
$CONTRIB/src/share
$CONTRIB/src/unit-test
$CONTRIB/src/example
$CONTRIB/doc
$CONTRIB/doc/taglib
* A skeleton build.xml is provided, which uses a set of
predefined ant-subroutines.
* An XML deployment descriptor for an user contribution could be
introduced, which contains essential information about name,
author, version, prerequisites, summary, unit test: yes/no,
example: yes/no, scope of contribution
(Action,ActionServlet,taglib,util).... . This deployment
descriptor could be used by an ant task for integration into the
main build process (e.g. dynamically building up the
documentation, building jars & wars, ...)
Since I have quite a lot of experience in building up and maintaining
large repositories, I really would like to contribute on this
issue (like the ant stuff or the deployment descriptor).
cu...
--
...roland huss
consol.de