Cocoon Documentation
The Cocoon Project is an Open Source volunteer project under the auspices of the Apache Software Foundation (ASF), and, in harmony with the Apache webserver itself, it is released under a very open license. This means there are many ways to contribute to the project - either with direct participation (coding, documenting, answering questions, proposing ideas, reporting bugs, suggesting bug-fixes, etc..) or by resource donations (money, time, publicity, hardware, software, conference presentations, speeches, etc...).
To begin with, we suggest you to subscribe to the Cocoon mailing lists (follow the link for information on how to subscribe and to access the mail list archives), to checkout the latest and greatest code (which you find in the xml-cocoon module in the xml.apache.org CVS code repository, or from the CVS snapshots), control the todo list and jump in. Document writers are usually the most wanted people so if you like to help but you're not familiar with the innermost technical details, don't worry: we have work for you!
For financial support in particular, the Cocoon Project and the ASF in general is closely collaborating with the Collab.net SourceXchange program that will provide a legal, solid and well-established resource for money collecting to fund software production under the open source flag. Please, feel free to contact directly the ASF President and Collab.net co-founder Brian Behlendorf for more information on how to contribute financially to the advancement of this project.
The rest of this document is mainly about contributing new or improved code and/or documentation, but we would also be glad to have extra help in any of the following areas:
cocoon-users
mailing list - there is often a problem of
having too many questioners and not enough experts to respond to all the questions.cocoon-dev@xml.apache.org
(you may also want to join xsp-dev@xml.apache.org
), install and try out Cocoon 2
and read some of the mail archives.
You should have a strong "fluency" in XML technologies, Java and a basic understanding of
the Cocoon 2 architecture - don't just say "it should have XYZ" without reading anything first -
because chances are, someone's already thought of that feature!).zip
and
.tar.gz
packages, but anyone is welcome to build their own specific packages and
announce them on cocoon-users
)
Thank you very much.
We are starting to use an informal system for accepting contributions to Cocoon. The process varies depending on whether the contribution is a modification (i.e. patch) or a fairly standalone item, and whether you have commit access (committers have been granted access by a vote of confidence, so they are assumed to be trustworthy enough to make changes directly in CVS. If you submit many good patches, you may be nominated as a committer yourself!)
If your contribution requires changing more than a few lines of Cocoon (code or documentation), then it counts as a patch. If you have a patch and would like to see it incorporated into the Cocoon distribution, take note of the Licensing Requirements listed below, and then read the Patch management page for more information.
Otherwise (that is, if it does not require patching or you are not particularly interested in having it included in the main distribution), your code and/or documentation can be listed on the Third-Party Contributions page. The rationale for this split is that core patches may fix important issues, and may require timely attention if they are not to go out-of-date and become useless, but other contributions can simply be downloaded and applied by users who wish to use them.
A typical contribution (not a patch) may go through the following stages:
contrib
directory,
which is for 3rd-party contributions that have been tested, but are not necessarily
mature enough or general enough for the main distribution. [Must be tested at least as
specified below. See also Licensing Requirements below.]These tests do not apply to Cocoon 2 because it is designed to have different minimum requirements. As Cocoon 2 is still alpha (at the time of this writing), we are not at a rigourous test stage yet. Stay tuned!
All new code should be tested under the following servlet engines:
It should also be tested on the following:
And obviously, it should be tested against the current CVS snapshot of Cocoon!
This testing is designed to iron out the most common kinds of incompatibilty problems (Servlet >2.0 requirements; platform-dependent assumptions; JDK >1.1 code). These requirements are, of course, open to review and discussion. Note that the contributor is not required to do the testing - indeed it is probably better if someone else tests it, because the contributor might be tempted to do less than thorough testing!
All new features (processor, logicsheets, config options etc.) should be documented appropriately (in XML or in cocoon.properties in the case of config options).
Use something like xdocs/index.xml
as a rough guide, add
the new page(s) to xdocs/site-book.xml
and xdocs/docs-book.xml
,
and type build.sh docs
or build.bat docs
to test the
documentation build.
To avoid legal problems, the Apache Project Management Committe (PMC) have agreed on a policy for under what licensing code can be accepted into Apache projects:
By submitting a patch, you signify your understanding and acceptance of these conditions - like most open source projects, we do not have the resources nor the inclination to obtain signed statements from all contributors!
Note: Since the contrib/
directory of Cocoon CVS contains
third-party. completely optional extensions, one of the above requirements is relaxed.
Code in the contrib directory does not have to have its copyright assigned to the ASF
- but it must still be released under the Apache license.
Copyright © 1999-2001 The Apache Software Foundation.
All rights reserved.