Apache cassandra

Clone this repo:
  1. 1d3edcb Add root Gradle front door; retire Makefile orchestration by Josh McKenzie · 4 weeks ago cep-63-root-gradle-front-door trunk
  2. a9def79 Add cassandra-ecosystem blended files by Josh McKenzie · 4 weeks ago
  3. d915cf0 Add 'sidecar/' from commit 'b3b412257629b53621136c8bc0cda33a35aefd93' by Josh McKenzie · 5 weeks ago
  4. 3e4d41c Add 'analytics/' from commit '30e69988976526fe208aefab7f8204897e647470' by Josh McKenzie · 5 weeks ago
  5. b2a5f16 Initialize cassandra-ecosystem repository by Josh McKenzie · 5 weeks ago

Apache Cassandra Ecosystem

Companion projects for Apache Cassandra®, co-located in a single repository so cross-cutting changes can be made, reviewed, tested, and released as one unit. This repository was created per CEP-63 by consolidating the former cassandra-analytics and cassandra-sidecar repositories.

What lives here

ProjectDirectoryWhat it isDocs
Analyticsanalytics/Spark bulk reader/writer connector for Cassandra (usable against non-Cassandra sources such as S3), the version-bridge layer, Spark/Avro converters, and the CDC implementation.README_ANALYTICS.md
Sidecarsidecar/Operational sidecar for Cassandra (health, rolling operations, streaming, CDC-to-Kafka) plus its client family and version adapters.README_SIDECAR.md

Each project is an independent Gradle build rooted in its own directory (its own settings.gradle, build.gradle, and gradle wrapper). Nothing about the individual builds changed as part of the merge, and today they still consume each other's published artifacts (0.4.0) rather than in-repo project dependencies. Breaking the remaining circular dependency (de-duplicating the Sidecar client, re-homing CDC) is a follow-up, not part of this initial consolidation.

Inclusion criteria (please read before proposing a new project)

To keep this repository focused and prevent it from becoming a “junk drawer”, a new top-level project may be added only if it is a companion to Apache Cassandra (not Cassandra core), is maintained by the Cassandra community, and benefits materially from co-location with the existing projects. Adding a new top-level project requires a lazy-consensus discussion on dev@cassandra.apache.org (or a follow-up CEP for anything large). Cassandra core does not live here.

Building

A thin top-level Gradle wrapper delegates into each project's own build, so you can drive both from the repo root. Tasks are grouped analytics*, sidecar*, and combined:

./gradlew analyticsJar          # assemble analytics only
./gradlew sidecarJar            # assemble sidecar only
./gradlew jar                   # assemble both
./gradlew check                 # static analysis on both
./gradlew test                  # unit tests on both
./gradlew clean                 # clean both
./gradlew tasks                 # list all analytics/sidecar/ecosystem tasks

The root build is pure orchestration — it never couples the two builds; each task just runs the child project's own ./gradlew. You can still build a project directly from its own directory (cd analytics && ./gradlew build).

The analytics build profile is selected with the SPARK_VERSION, SCALA_VERSION, and JDK_VERSION environment variables (e.g. SPARK_VERSION=4 SCALA_VERSION=2.13 JDK_VERSION=17); these pass straight through to the child build. Integration tests need dtest jars first — run ./gradlew analyticsDeps / ./gradlew sidecarDeps (network) before ./gradlew analyticsIntegrationTest / sidecarIntegrationTest.

Versioning & releases

All modules share a single, lock-step version line (both projects are currently 0.5-SNAPSHOT). ./gradlew setVersion -Pversion=x.y.z stamps the same version into both analytics/gradle.properties and sidecar/gradle.properties (./gradlew printVersion shows the current values); a release that only changes one project still bumps the other (noted in release notes). Published artifact names and coordinates are unchanged by the merge — analytics artifacts keep their ..._sparkN_scala suffixes and sidecar keeps its sidecar-* names.

Continuous integration

CI runs per-project and only exercises what changed:

  • GitHub Actionsanalytics-ci.yml and sidecar-ci.yml. Each always runs but gates its heavy jobs behind a change-detection step; an always-running aggregator (“Analytics CI Gate” / “Sidecar CI Gate”) is the single required status check per project, so a single-project PR merges cleanly while real failures still block.
  • CircleCI — dynamic config (.circleci/config.ymlcontinue-config.yml) uses path filtering to run only the changed project's workflow. Requires CircleCI “dynamic config” to be enabled (INFRA).

Per-project references

Contributing

Contributions are welcome. Join #cassandra-dev in ASF Slack. Issues are tracked in separate Jira projects — CASSANALYTICS for Analytics and CASSSIDECAR for Sidecar.

License

Apache License 2.0 — see LICENSE.txt.