Contributions are always welcome. The preferred way to submit a patch is to attach it to
a bug or feature request in the SourceForge database. Remember that patches for documentation
or additional test cases are just as valuable as code patches.
In order to be successfully merged, patches must be generated from the most recent code in svn.
Refer to "Getting Latest Code" for information on retrieving
and building the latest code.
Rules for submitting patches
These rules are intended to reduce the effort that the maintainers need to do when accepting
a patch. If the patch requires too much effort to "clean up" before being merged then it will
likely be rejected. Remember that everyone working on this project is volunteering their time
so lets be considerate.
Make sure the code follows the coding conventions
already in use. Refer to the link above to
see the coding conventions that we are using here. We use checkstyle to enforce
many of the coding standards (some things like good naming can't be easily checked
with a tool but we check as much as we can automatically). The maven build should
perform these checks for you.
Make sure the new code has automated unit tests written for
JUnit. No code will get merged without tests.
Whenever possible, tests classes should extend WebDriverTestCase.
If you are fixing a bug but not adding new functionality then we still require
tests that would fail with the old behavior.
All existing unit tests must pass.
All files must be copyright Gargoyle Software Inc.
and must be licensed under the same
license as the rest of the project - currently an Apache
style one. This is required so that we can make sweeping changes such as the license
change that we already did (from LGPL to Apache style).
All non-private methods must have full javadoc before we put out a release. Putting
javadoc on private methods is a good practice as well but isn't required. If you
make changes to a given file then you are expected to add an author tag at the top
of the file. @author tags are written in chronological order with the original
author at the top. Refer to
How to Write JavaDoc for more specific information on javadoc.
Patches should be in "unified diff" format.
Please provide only one patch that contains all the files. Some people
will submit separate patches for each file in the diff and this just
makes more work for the committer. Please also submit it as one single diff,
not zipped up - again because it's easier for the committers.
IMPORTANT: Patches without tests will be rejected. Occasionally
one of the committers will have the time to write the tests for you but this
is rare. If you are not sure how to write a test for a given situation then
ask on the developer mailing list.
Additional documentation or code samples are always appreciated. We're focused on writing
code and documentation often gets neglected.