Guidelines for Code Contributions & Patches

We are very appreciative of code contributions.

But before sending Java source code contributions please make sure that the changes match our coding guidelines. In addition to these coding guidelines, we use the Checkstyle tool to ensure that all of the source code follows a consistent style.

To help you achieve this you need to execute the command build.bat checkstyle on Windows or ./build.sh run-checkstyle on Linux/UNIX. If this target fails you find the list of coding style violations in the file checkstyle-results.txt in the build folder. Please fix the issues listed there before sending any diffs, otherwise one of the developers applying the patch needs to do fix this for you or may even reject the patch.

If your changes are large and you forgot to follow the coding guidelines from the beginning you can use the tool astyle to apply some of the guidelines automatically. To do this run the command

astyle -j -s4 -b -P --convert-tabs --break-blocks

on your code.

Patches should be generated using diff -u or cvs diff -u (unified diff). Always create patches against the latest CVS to check whether the problem, you are addressing with your patch, still exists in the latest version. Create the patch from the root directory of the module, e.g.

cvs diff -u src/main/org/openorb/iiop/CodeSetDatabaseInitializer.java > CodeSetDatabaseInitializer.java.diff

The patch can then easily be applied from the root of the module by typing:

patch -p0 < CodeSetDatabaseInitializer.java.diff

Patches should be submitted either as:

• plain text attachments to email sent to the openorb-devel mailing list or
• attachments for a bug report.

If you paste the diff into the body of an email or into Bugtracker's description field, it is hard to extract the patch because of formatting issues like DOS/UNIX line breaks or line breaks after 72 characters as email programs use to do.

If you follow these guidelines you can be sure that your patch will be reviewed and applied without delay (Under the assumption of course that a developer has currently time to do it ;).