I agree with Mazz about the tests: tests should be predictable and fail
only when there's a failure on the *code*, so, having to install a
database, or having pre-existing data should *not* be something that
would break tests. At least for JPA modules, it's common to use an
embedded database for the tests, while the real module uses datasources
configured on the application server.
This problem could be avoided by having the integration tests to add the
embedded Cassandra WAR to the nest, binding it to a different port (to
avoid conflicting with possible Cassandra nodes running on the machine).
For dev builds: I'm not sure I like the idea of having embedded
Cassandra for dev builds but not for release builds. IMO, we should try
to not deviate too much, specially because we would catch problems only
when it's "too late". I'd rather require developers to install Cassandra
locally, on this scenario.
- Juca.