Contributing and code review

If you have created a Gerrit account and followed the steps in How to access the HALE sources it is very easy to contribute changes. For any commit you created and pushed to Gerrit (refs/for/*) a new change request is created in Gerrit. Developers then can review, comment and vote on the change request. Comments can be made either on the change in general or in detail on the diff.

Changes to the existing code need legal file headers for the new files and a statement (as a comment on the change in Gerrit) confirming that you wrote 100% of the code yourself, and that you have the right to contribute it under the LGPL.
For contributions of whole modules/plug-ins, especially if to be licensend based on other conditions (e.g. GPL), please contact us.

For a change to be submitted it needs to be voted +1 in the category Verified and +2 in the category Code review. Once a change is submitted its status changes to MERGED and it is available in the repository. If submission fails it may be needed to adapt the change, resolving any conflicts with respect to the server repository.

Every change or patch set that is pushed to Gerrit results in a build being triggered on the Jenkins Build Server. Jenkins will vote +1 on Verified if the build succeeds, -1 on Verified if the build fails and -1 on Code review if the build is unstable. Jenkins will leave a comment with a link to the triggered build so you can have a closer look at the results.

More detailed information

Conventions

Commit message

When working on a tracked issue commits should reference the issue number to allow easily associating commits with the corresponding issue and vice versa. To achieve this, include a line refs #$ISSUE in the commit message, where $ISSUE is to be replaced by the issue number.
Here is an example commit message:

Adapted TypeHierarchyView to be able to deal with EntityDefinitions

This is needed because the schema explorer now provides a selection
consisting of EntityDefinitions that consist of the whole definition
path.

refs #333

Change-Id: I5041676a6f42418b607045a54099f639a8548ad6

Project preferences

We use a Groovy script apply-preferences.groovy to set the preferences for new projects or update the preferences of existing projects.
When creating a new project in the default HALE plugin folders, just run the script to set the project preferences. If creating projects in a subfolder of the ext directory, you can manage the project preferences on your own, though it is recommended to use similar settings for compiler warnings as in the main projects.

Part of the preferences are also templates for the code comments. If you want to use another default author name than your login name, just add

-Duser.name=Your Name

to the eclipse.ini-File of your Eclipse installation - just make sure you add it after the -vmargs-Line.

JUnit tests

The build process will recognize all bundles or fragments whose name end with .test as test bundles/fragments and will try to execute tests contained in that bundle. The bundles/fragments must be part of the product definition. Test class names must end with Test to be taken into account. If a test requires a special launch configuration it should be saved to a shared launch file in the META-INF/tests folder in the test bundle/fragment.