Code contribution guidelines

[greenmail-mail-test]

Code contribution guidelines

[camann9]

Will put this into the readme.md so it gets displayed on the github front page.

[buildscientist]

👍

Thanks - I will say I was a bit frustrated by the code line policy. I'm used to submitting PR's from master as opposed to feature branches but I do understand the benefit of separating out change-sets.

Regarding the formatting - should we employ the use of something like Checkstyle.

Also is there any reason why we're using a relative path for child POM's to reference greenmail-parent

<relativePath>../pom.xml</relativePath>

If we just have a definition for greenmail-parent then we don't need to actually define dependencies like JavaMail etc in greenmail-core. It seems a little redundant to have to define dependencies in two locations (greenmail-core and greenmail-parent).

[camann9]

The thing I want is that the differences view for the pull request is clean (only the actual changes are visible). This can be reached most easily if you create new branches for every pull request I think.

We actually have checkstyle, just that we don't have Sonar to show the errors. But the checkstyle report should be in the generated site. I wouldn't rely on it that much though because there are still a lot of problems since noody ever really looked at this report.

The concept we are using for dependency management is called BOM (bill of material): http://blog.inflinx.com/2013/12/29/maven-bill-of-materials/ . We have a parent POM that defines the versions for all the artifacts we can use in the project in a dependencyManagement/dependencies section. If one of the child projects wants to actually include one of the artifacts it has to add a dependency in the dependencies section. Be aware that the sections of the POM that are used in parent and child are different. I hope this clarifies your questions.