Chapter 1. How to get help and contribute on Hibernate OGM

Hibernate OGM is a young project. The code, the direction and the documentation are all in flux and being built by the community. Join and help us shape it!

1.1. How to get help

First of all, make sure to read this reference documentation. This is the most comprehensive formal source of information. Of course, it is not perfect: feel free to come and ask for help, comment or propose improvements in our Hibernate OGM forum.

You can also

open bug reports in JIRA
propose improvements on the development mailing list
join us on IRC to discuss developments and improvements (#hibernate-dev on freenode.net; you need to be registered on freenode: the room does not accept "anonymous" users).

1.2. How to contribute

Welcome!

There are many ways to contribute:

report bugs in JIRA
give feedback in the forum, IRC or the development mailing list
improve the documentation
fix bugs or contribute new features
propose and code a datastore dialect for your favorite NoSQL engine

Hibernate OGM's code is available on GitHub at https://github.com/hibernate/hibernate-ogm.

1.2.1. How to build Hibernate OGM

Hibernate OGM uses Git and Maven 3, make sure to have both installed on your system.

Clone the git repository from GitHub:

#get the sources
git clone https://github.com/hibernate/hibernate-ogm
cd hibernate-ogm

Run maven

#build project
mvn clean install -s settings-example.xml

Note

Note that Hibernate OGM uses artifacts from the Maven repository hosted by JBoss. Make sure to either use the -s settings-example.xml option or adjust your ~/.m2/settings.xml according to the descriptions available on this jboss.org wiki page.

To build the documentation, set the buildDocs property to true:

mvn clean install -DbuildDocs=true -s settings-example.xml

If you just want to build the documentation only, run it from the hibernate-ogm-documentation/manual subdirectory.

1.2.2. How to contribute code effectively

The best way to share code is to fork the Hibernate OGM repository on GitHub, create a branch and open a pull request when you are ready. Make sure to rebase your pull request on the latest version of the master branch before offering it.

Here are a couple of approaches the team follows:

We do small independent commits for each code change. In particular, we do not mix stylistic code changes (import, typos, etc) and new features in the same commit.
Commit messages follow this convention: the JIRA issue number, a short commit summary, an empty line, a longer description if needed. Make sure to limit line length to 80 characters, even at this day and age it makes for more readable commit comments.
```
OGM-123 Summary of commit operation

Optional details on the commit
and a longer description can be
added here.
```
A pull request can contain several commits but should be self contained: include the implementation, its unit tests, its documentation and javadoc changes if needed.
All commits are proposed via pull requests and reviewed by another member of the team before being pushed to the reference repository. That's right, we never commit directly upstream without code review.