Volunteers

All work on OpenJMS is provided on a volunteer basis. We are always looking for volunteers to help make OpenJMS a great project.

There are a variety of ways to participate. You can:

Regardless of how you choose to participate, we suggest you to join the mailing lists first.

Providing feedback

Using OpenJMS, reporting bugs , making enhancement requests , et cetera, are very important. Your feedback allows OpenJMS to evolve.

Mailing lists and forums

The sourceforge site provides several mailing lists and forums

All posts to the forums also get forwarded to the user mailing list.

Contributing code or documentation

Want to contribute code or documentation? Excellent!

If you want to contribute, but don't know where to start, take a look at the list of outstanding bugs , enhancement requests and the Roadmap

Coding Conventions

Following is a list of coding conventions specific to OpenJMS. Anything not specifically mentioned here should follow the Sun Java Coding Conventions.

  1. 4 space indent. NO tabs.
  2. JavaDoc MUST exist on all methods. If your code modifications use an existing class/method/variable which lacks JavaDoc, it is required that you add it. This will improve the project as a whole.
  3. If you contribute to a file (code or documentation), add yourself to the authors list at the top of the file. For java sources, the preferred format is 
    @author <a href="mailto:user@domain.com">John Smith</a>

Code not following coding conventions will be listed in the checkstyle report

Documentation

Documentation is perhaps the most important and most overlooked aspect of any opensource project. Good documentation reduces support requests, and lowers the bar of entry to the use of the software.

All of the OpenJMS documentation is in xdoc format, and is transformed to HTML using Maven . See the xdoc plugin for a description of the format.

The OpenJMS documentation can be found in the src/xdocs directory in the CVS repository and source distribution.

Submitting changes

When submitting changes to OpenJMS, the changes should be presented in the form of input to the patch command.

Patches can be attached to a bug report or enhancement request, or sent to the developer mailing list.

When sent to the mailing list, the message should contain a Subject beginning with [PATCH] and a distinctive one-line summary in the subject corresponding to the action item for that patch.

The patch should be created by using the cvs diff -u command. It is recommended that you submit patches against the latest CVS version of OpenJMS in order to avoid conflicts. This will also ensure that you are not submitting a patch for a problem that has already been resolved.

For example: 

    cvs diff -u Foo.java >> patch.txt

All patches necessary to address an action item should be concatenated within a single patch message. If later modification to the patch proves necessary, the entire new patch should be posted and not just the difference between the two patches.

If your email client line wraps the patch, attach the patch to the associated bug report/enhancement request.