How to Contribute To Hama
Getting the source code
First of all, you need the Hama source code. The official location for Hama is the Apache SVN repository; Git is also supported, and useful if you want to make lots of local changes -and keep those changes under some form or private or public revision control.
SVN access
Get the source code on your local drive using SVN. Most development is done on the TRUNK:
svn checkout http://svn.apache.org/repos/asf/incubator/hama/trunk hama-trunk
Git access
Making Changes
Before you start, send a message to the Hama developer mailing list, or file a bug report in Jira. Describe your proposed changes and check that they fit in with what others are doing and have planned for the project. Be patient, it may take folks a while to understand your requirements.
- Jira usage guidelines
Modify the source code and add some (very) nice features using your favorite IDE.
But take care about the following points
- All public classes and methods should have informative Javadoc comments.
- Code should be formatted according to hama-code-formatter
- Contributions should pass existing unit tests.
- New unit tests should be provided to demonstrate bugs and fixes.
Generating a patch
Please make sure that all unit tests succeed before constructing your patch and that no new javac compiler warnings are introduced by your patch.
> cd hama-trunk
> mvn install package
> mvn -Pexamples package
> mvn -Pforrest package -Dforrest.home={$FORREST_HOME}
After a while, if you see
BUILD SUCCESSFUL
all is OK.
Creating a patch
Check to see what files you have modified with:
svn stat
Add any new files with:
svn add src/.../MyNewClass.java
In order to create a patch, type (from the root directory of hama):
svn diff > HAMA-321.patch
This will report all modifications done on Hama sources on your local disk and save them into the HAMA-321.patch file. Read the patch file. Make sure it includes ONLY the modifications required to fix a single issue.
Stay involved
Contributors should join the Hama mailing lists. In particular, the commit list (to see changes as they are made), the dev list (to join discussions of changes) and the user list (to help others).
Coding convention
- Variables should be meaningful so that they are easily understood by other developers. For instance, the declaration of 'String serverName' would be better than 'String str'.
- Indentation is 2 spaces, not 4.
- Argument checks for NullPointerException, IlleagalArgumentException, etc.