PicoContainer is nothing without contributions from the user community. There are many ways to contribute. We are constantly working on the software and documentation, so it's a good idea to contact the team on the user or development mailing lists to avoid duplicating effort.
One of the traditional weak points of open source software is the documentation. Any help with this aspect of the project will be welcomed with open arms, or at the very least with open email clients!
It would be fantastic if someone wanted to contribute with some examples. Please use our JIRA for this.
If you want to request a new feature you can either make a request through the issue tracker or by sending a message to the development mailing list. The benefit of any new features will be discussed on the mailing list, so its a good idea to sign up so that you participate in the discussion.
You can report bugs through the issue tracker interface or the development mailing list. Additional pico points are awarded for bug reports that include a failing unit test.
If you think you have found a design flaw in PicoContainer that you'd like to improve, please present your ideas on the developer mailing list and explain. Wait for someone to reply and see the outcome before submitting a patch. This will save a lot of time for both you and the developers.
However, if the improvement is really obvious and requires no discussion, just stick it in JIRA right away.
Use UnifiedPatch for this.
If you want lots of pico points, submit a fix in JIRA along with a description and unit test(s) (For bugs, it is OK to submit a failing test that highlights the bug).
Fixes are best sent as unified patch that we can apply to the codebase. Remember to tell us which version the patch should be applied against, or we'll get very confused. To be accepted into the codebase, patches must be released under the same license as PicoContainer itself. Also, please respect the coding standards and formatting. Don't reformat the existing code, as this makes it impossible for us to determine what you have changed.
If you have modified some files to fix something yourself, don't attach the modified files (as this prevents us from seeing what your changes consist of). Instead, make a unified patch of your locally modified sources (standing in the root folder of your local CVS copy):
cvs -q diff -b -u -N > patch-1.diff
Then attach patch-1.diff to an existing JIRA issue, or make a new Bug/Improvement
issue if none exists. You should only attach entire files if they are new files (not yet
in CVS).
If you want to submit a new and improved patch at a later time, please name it patch-2.diff etc.
The developers will then be able to apply the patch by issuing the following command
from the root folder:
patch -p 0 < patch-1.diff
If you have a new feature request, then we'll listen extra hard if you show us how it works. A new feature might be best implemented as a patch to an existing class or as a new class. The PicoContainer API contains many extension points that allow new functionality to be integrated into the framework. We are rather anal about testing, so if you send us some code without any tests we will probably ask you to write the tests tests as well before we add it to the codebase.
If you have a reusable extension to PicoContainer (perhaps a fancy ComponentAdapter), we will be happy to include it directly into the PicoContainer or into a NanoContainer subproject project.
We follow The Codehaus Manifesto when it comes to expanding the core team. We'll invite you, rather than you apply