Quick Links:

Releases | Mailing Lists | Source Control | Issue Tracker | Regression Tests


Contributing Documentation

The website and the user guide are built from the contents of our GitHub repo . If you want to help us improve our User Guide and other online documentation, please send your patches to the core mailing list or open a pull request on GitHub.

Contributing Code

If you have extended Jikes RVM and would like to contribute your extension back to the community, please use the patch tracker to submit your contribution. If you do not want to create an account on the patch tracker, you can also send your patches to the core mailing list. Please include the following in both cases:

Your contribution will be licensed under the EPL (Eclipse Public License), the license used for Jikes RVM. The license has been approved by the OSI (Open Source Initiative) as a fully certified open source license. If your contribution is included in the system, you will be acknowledged on the contributors web page, along with getting the satisfaction of making the world a better place.

Getting your code contribution merged

You should make it easy for members of the Jikes RVM team to merge your code contribution.

At minimum, you must do the following:

  1. Make sure that your contribution follows our coding style and the coding conventions. Use Checkstyle (e.g. via “ant checkstyle”) to check for common errors.
  2. After verifying that there are no checkstyle errors, run the pre-commit tests on your machine.
  3. After the pre-commit run is done, you can find the report at results/tests/pre-commit/Report.html in your jikesrvm directory. It should read something like “Total Success Rate: 128/128” (numbers from August 2012). The report will also display the revision number, if applicable. If the revision number ends with a +, you have uncommited changes in your working copy. Check that the uncommited changes are not supposed to be in your patch.

The Jikes RVM team will check for those points.

You can do the following things to further increase the chances that your contribution will be merged:

Contributing patches

Patches should apply against a revision of the main repository. This ensures that your patch can always be applied easily. If you’re providing a series of patches, each patch should produce a working system that passes pre-commit.

Contributing using pull requests

Use the normal GitHub workflow to submit a pull request at either the main repository (for code) or the github.io repository (for the website).

Statement of origin

All contributions must include one of the Statements of Origin below. Insert your name(s) in the first blank(s) and a high-level summary in the blank in a (i) . Examples of a high-level summary are “Fixed bug in scheduler”, “Extended type propagation in optimizing compiler”, or “Added new garbage collector”.

If your contribution is owned by your employer, someone authorized by your employer to make such a decision must add a comment to the patch in the tracker stating that you have permission to contribute it.

Statement of Origin : Single Contributor Single Contributor for all Contributions Multiple Contributors