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.
| Project | Directory | What it is | Docs |
|---|---|---|---|
| Analytics | analytics/ | 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 |
| Sidecar | sidecar/ | 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.
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.
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).
Each project runs on the JDK it needs, whichever JDK launched ./gradlew: analytics on JDK_VERSION if set, otherwise its analyticsJDKLevel default (JDK 17), and sidecar on JDK 11 (-PsidecarJdkVersion=17 overrides it). Gradle finds installed JDKs through toolchain detection; ./gradlew javaToolchains lists the ones it sees, and org.gradle.java.installations.paths points it at others. On macOS, a Homebrew JDK is only detected once it is linked into /Library/Java/JavaVirtualMachines (see brew info openjdk@11).
The analytics build profile defaults to Spark 4 / Scala 2.13 / JDK 17 and is selected with the SPARK_VERSION, SCALA_VERSION, and JDK_VERSION environment variables (e.g. SPARK_VERSION=3 SCALA_VERSION=2.12 JDK_VERSION=11); these pass straight through to the child build.
Both projects compile against an in-jvm dtest jar built from Cassandra sources, so analyticsJar / sidecarJar (and jar) first build the one jar each needs (analyticsJarDeps / sidecarJarDeps). The first run needs network access and takes a while; later runs skip the step while the jar exists. Integration tests need the full set — run ./gradlew analyticsDeps / ./gradlew sidecarDeps before ./gradlew analyticsIntegrationTest / sidecarIntegrationTest. The dtest scripts add GitHub's SSH host key to ~/.ssh/known_hosts (ssh-keyscan) before cloning.
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.
CI runs per-project and only exercises what changed:
analytics-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/config.yml → continue-config.yml) uses path filtering to run only the changed project's workflow. Requires CircleCI “dynamic config” to be enabled (INFRA).Contributions are welcome. Join #cassandra-dev in ASF Slack. Issues are tracked in separate Jira projects — CASSANALYTICS for Analytics and CASSSIDECAR for Sidecar.
Apache License 2.0 — see LICENSE.txt.