First read The Akka Contributor Guidelines .
The Akka code style follows the Scala Style Guide . The only exception is the style of block comments:
/** * Style mandated by "Scala Style Guide" */ /** * Style adopted in the Akka codebase */
Akka is using Scalariform to format the source code as part of the build. So just hack away and then run sbt compile and it will reformat the code according to Akka standards.
- Make sure you have signed the Akka CLA, if not, sign it online.
- Pick a ticket, if there is no ticket for your work then create one first.
- Start working in a feature branch. Name it something like wip-<ticket number>-<descriptive name>-<your username>.
- When you are done, create a GitHub Pull-Request towards the targeted branch and email the Akka Mailing List that you want it reviewed
- When there's consensus on the review, someone from the Akka Core Team will merge it.
Please follow these guidelines when creating public commits and writing commit messages.
- If your work spans multiple local commits (for example; if you do safe point commits while working in a topic branch or work in a branch for long time doing merges/rebases etc.) then please do not commit it all but rewrite the history by squashing the commits into a single big commit which you write a good commit message for (like discussed below). Here is a great article for how to do that: http://sandofsky.com/blog/git-workflow.html. Every commit should be able to be used in isolation, cherry picked etc.
- First line should be a descriptive sentence what the commit is doing. It should be possible to fully understand what the commit does by just reading this single line. It is not ok to only list the ticket number, type "minor fix" or similar. Include reference to ticket number, prefixed with #, at the end of the first line. If the commit is a small fix, then you are done. If not, go to 3.
- Following the single line description should be a blank line followed by an enumerated list with the details of the commit.
Completed replication over BookKeeper based transaction log. Fixes #XXX * Details 1 * Details 2 * Details 3
All code that is checked in should have tests. All testing is done with ScalaTest and ScalaCheck.
- Name tests as Test.scala if they do not depend on any external stuff. That keeps surefire happy.
- Name tests as Spec.scala if they have external dependencies.
There is a testing standard that should be followed: Ticket001Spec
Included in the example is an sbt trait for multi-JVM testing which will fork JVMs for multi-node testing. There is support for running applications (objects with main methods) and running ScalaTest tests.
You can use the 'NetworkFailureTest' trait to test network failure.