Remove a bunch of unused imports.
Rename an internal property: bucket -> name
Expose the name of the bucket as a trait property.
Ensure the resolved conflict was actually written back to the database.

Prior to this the test verified that the resolved conflict could be read repeatedly, but this could be due to repeated resolution using the resolver.
This test verifies the resolved conflict has been written back to Riak by using an independent bucket to read the result; the independent bucket has no resolver configured, meaning it will throw an exception if the siblings are still present in the database.
Merge pull request #18 from asnare/unused-import-tidyup

Remove a bunch of unused imports.
Removed scct from the build
Set current version to 0.8.4.2-dev
Merge pull request #19 from asnare/fix-conflict-resolver-writeback-spec

Fix a test; it wasn't fully testing that resolved conflicts are written to the database.
Removed unvalidated assumptions about the default bucket properties of a developer's test system

Thanks to @asnare for the warning about making assumptions about default property values.
Set the new version to 0.8.4.1
Don't specify the return type; it's inherited, and the overriding method always throws an exception anyway.
Modify conflict resolution so that write back is optional. (API-breaking change.)

Instead of always writing the results of a conflict back to the database, allow the resolver to indicate whether this should take place or not.
In many situations it turns out we don't want to unconditionally write the value back:
 - Often the resolved value is going to be updated and written back anyway. Skipping the intermediate write is a win.
 - Always writing back resolved values can lead to runaway sibling chains when multiple readers access the same key.
 - Resolving conflicts is normally very cheap compared to writing back to the database. As such the cost of a write back is not necessarily worth it, performance wise.

Writeback should only be avoided if the resolver is pure/idempotent: for a given set of siblings (in any order) it should always yield the same result.
No need to explicitly qualify successful(); it's already in scope.
Use more idiomatic field extraction.
Verify that resolved siblings are not written back to the database if the resolver does not specify write-back.
Merge pull request #21 from asnare/conflict-resolver-optional-writeback

Optional writeback when resolving conflicts

This pull request changes the conflict-resolution mechanism so that writing the resolved sibling back to the database becomes optional. This is an API-breaking change, in that conflict resolvers now return a resolved sibling and whether it should be written back or not. (Previously it was always written back.)

This is a fairly crude first iteration at improving the conflict-resolution mechanism. In the future it could be improved further by delegating the decision to the driver, which could use some heuristics (eg. sibling count, amount of data read) to conditionally write the result back.

The commits themselves contain more information about the changes I've made.
Update plugins.sbt
Update coverage.sbt
Merge pull request #22 from D-Roch/patch-1

Update plugins.sbt
Update to current SCCT plugin.