How do I contribute, give feedback, fix bugs and so on?

The Apache Harmony project really needs and appreciates any contributions, including documentation help, source code and feedback. Suggested changes should come in the form of source code and/or very detailed and constructive feedback.

• Discussion occurs on the Harmony mailing lists
• Informal discussion also occurs on the #harmony IRC channel on freenode.net. (Help with IRC)
• Information on access to the project source code is available here.
• Bugs and other issues can be posted on the project JIRA
• Step-by-step instructions on reporting, resolving and closing issues are listed in Good Issue Resolution Guideline
• Additional documentation and discussion can be found on the project wiki

Back to top

Am I Eligible?

You may have heard or read about Harmony's strict rules for contributor's eligibility. We take this seriously because a number of parties implement Java, and we respect their rights to their property. If you have detailed knowledge of another implementation of Java, and they have not explicitly approved your participation in Harmony, please check whether we will be able to accept your contribution by reading the Apache Harmony contribution policy.

Back to top

How to Create and Submit A Patch or Enhancement

One of the best ways to get involved in the Harmony project is to create patches or additions and contribute them. When you propose a specific change to the software for discussion or voting on the mailing list, you should present in the form of input to the patch command. All contributions should be made via a new entry in our project JIRA.

Change-offering Tips

• Once you have completed your changes, please be sure to test your changes very well. When changing the code base, be sure that it builds cleanly and the full test suite passes before submitting. Patches that break the build or break the code will be rejected.
• If you are offering...
  • A fix to a bug, please provide a test case and instructions to help us reproduce the bug, and then test that the bug is fixed. We will add the test case to our test suite.
  • A change to documentation or the website, review the generated output and be sure that it is as you expect.
  • New data, include the entire file that you are contributing.
• When you are offering a change to something that already exists in the project SVN repository, submit a patch as outlined below.

Guidelines on how to Create and Submit a Patch

Once you are sure you have tested/reviewed your changes, do the following:

• Open a new JIRA entry.
• Clearly describe the patch or enhancement, and provide details, such as how to re-create if a bug, why the change or enhancement is useful, etc.
• Use the subversion diff utility to create a patch as follows:

  svn diff file.java > file.patch

  where file is the filename that you have changed. This will produce a nice patch file that can be added to the JIRA, which makes it easy for the project committers to review and possibly accept your patch.
  

  Example

  diff -u http_main.c.orig http_main.c >> patchfile.txt

  Note that the diff command only shows differences for text files, and not binary files. So even if you did svn add on a binary file (gif, jar, png etc.), it won't show up in the patch, and will fail to apply. The key string to look out for in the patch is:

  Cannot display: file marked as a binary type. 

  If you see that, you'll also need to attach the binary files that have changed separately to the issue. To get a list of such files in file.patch, run:

  grep -B 2 "Cannot display" file.patch

• Attach all materials to the JIRA entry via Attach File.
• Be sure to select Grant license to ASF for inclusion in ASF works.... Any patch without this grant will be rejected.

Back to top