+1 much needed improvement to our build process. Jaydeep
On Wed, Apr 29, 2026 at 7:58 PM Dinesh Joshi <[email protected]> wrote: > +1 > > Love it. Thanks David! > > On Wed, Apr 29, 2026 at 6:59 PM Jon Haddad <[email protected]> > wrote: > >> Love this. >> >> cassandra-easy-stress also uses Gradle, fwiw. >> >> On Wed, Apr 29, 2026 at 2:59 PM Isaac Reath <[email protected]> wrote: >> >>> +1. We already have Gradle in our build process, it'd be great to make >>> it first class. >>> >>> On Wed, Apr 29, 2026 at 11:06 AM Josh McKenzie <[email protected]> >>> wrote: >>> >>>> *Plus.* >>>> *One.* >>>> >>>> On Tue, Apr 28, 2026, at 7:22 PM, David Capwell wrote: >>>> >>>> I'd like to propose adding Gradle build support to the project. This is >>>> not a proposal to remove ant -- ant remains the primary build system. The >>>> patch (PR #4778) adds gradle as an opt-in developer tool that sources its >>>> configuration from ant's build.xml, layering gradle's task graph and >>>> caching on top of what we already have. >>>> >>>> **What the patch does** >>>> >>>> Gradle wraps ant's existing configuration. You maintain ant as before; >>>> gradle reads from it. The result is a developer experience layer on top of >>>> our current build: >>>> >>>> ``` >>>> $ ./gradlew test --tests org.apache.cassandra.utils.UUIDTest --rerun >>>> BUILD SUCCESSFUL in 2s >>>> 27 actionable tasks: 1 executed, 26 up-to-date >>>> ``` >>>> >>>> Compare this to the correct way to run a single test via ant that >>>> matches what CI actually executes and doesn't rebuild unneeded work: >>>> >>>> ``` >>>> $ # human validates that the cache is still valid... did you change the >>>> JDK? Did any file change? Human must maintain this in their head >>>> $ ant -Dant.gen-doc.skip=true \ >>>> -Dno-checkstyle=true \ >>>> -Dant.gen-doc.skip=true \ >>>> -Drat.skip=true \ >>>> -Dno-build-test=true \ >>>> testclasslist \ >>>> -Dtest.timeout=480000 \ >>>> -Dtest.classlistprefix=unit \ >>>> -Dtest.classlistfile=<(echo org/apache/cassandra/utils/UUIDTest.java) >>>> ``` >>>> >>>> Most developers use `ant test-some` instead because of this complexity, >>>> but `test-some` uses different JVM arguments than `testclasslist` (which is >>>> what CI runs). This means test failures in CI may not reproduce locally >>>> because the developer ran the test differently. With gradle there is one >>>> way to run a test; local and CI do not have different behaviors. >>>> >>>> **Why Gradle and not Maven** >>>> >>>> This question has come up in every prior discussion, so let me address >>>> it directly. >>>> >>>> 1. **The ecosystem already chose Gradle.** Accord, Sidecar, and >>>> Analytics are all Gradle projects. Choosing Maven for the server would mean >>>> three subprojects on Gradle and one on Maven. Accord integration is the >>>> clearest example of the problem: today, ant works around Accord being a >>>> Gradle project by having Accord *publish* artifacts to the user's local >>>> Maven repository, then ant resolves them from there. Maven would have the >>>> same problem -- it would also need Accord to publish locally before the >>>> server build can proceed. With Gradle, there's no publish step at all. >>>> Gradle understands how to build Accord directly via composite builds: >>>> >>>> ```groovy >>>> includeBuild('modules/accord') { >>>> dependencySubstitution { >>>> substitute module('org.apache.cassandra:cassandra-accord') >>>> using project(':accord-core') >>>> } >>>> } >>>> ``` >>>> >>>> Gradle builds Accord from source as part of the server build. No >>>> intermediate publish, no stale local artifacts, no coordination. >>>> >>>> 2. **Maven forces us into its model; Gradle lets us keep ours.** Over >>>> the years with ant we've grown a number of custom solutions to problems -- >>>> custom test execution, custom artifact assembly, custom dependency >>>> handling. These work for us. Maven's opinionated structure (one artifact >>>> per POM, standard lifecycle phases, rigid directory layout) would require >>>> us to restructure the project to fit Maven's expectations. We'd be fighting >>>> the tool. Gradle lets us express our existing custom workflows naturally >>>> while still benefiting from a modern build system's caching, dependency >>>> resolution, and task graph. >>>> >>>> 3. **Maven can't wrap ant.** The approach in this patch -- gradle >>>> sourcing ant's config so we incrementally adopt without a big-bang rewrite >>>> -- isn't possible with Maven. A Maven migration would require rewriting >>>> build configuration from scratch, which is exactly the kind of disruption >>>> that has killed every prior proposal on this mailing list. >>>> >>>> 4. **Incremental builds are first-class in Gradle.** Maven's >>>> incremental story requires plugins and is unreliable in practice. Gradle's >>>> task avoidance and build cache are core features. >>>> >>>> 5. **Gradle version stability -- an honest assessment.** The concern >>>> about Gradle version churn is legitimate. We pin a specific version via the >>>> wrapper (Gradle 9 in this patch), so day-to-day there is no drift. However, >>>> when we do need to upgrade -- for example, to pick up JDK support for a new >>>> Java version -- there is real risk of breaking changes requiring work. If >>>> we release annually, we may need to update Gradle annually, and that could >>>> require effort. >>>> >>>> Two things that mitigate this: First, Gradle has improved its >>>> deprecation cycle -- they warn for a full major version before removing >>>> APIs, giving upgrade windows. This patch already addressed Accord's Gradle >>>> 8 to 9 migration, which involved deprecation warnings (not breakage) that >>>> will become errors in 10.x. Second, AI tooling dramatically lowers the >>>> migration cost. This patch itself was written by Claude opus and it had no >>>> issues understanding Gradle's conventions and generating the correct >>>> configuration. Future version upgrades are well-suited to the same approach >>>> -- the tool reads the migration guide, reads our config, and produces the >>>> update. >>>> >>>> **Maintenance cost** >>>> >>>> I want to be clear-eyed about this: "gradle sources ant" means there is >>>> minimal maintenance overhead *for the current project structure*. If we had >>>> this patch 5 years ago, there would have been zero drift in that time. But >>>> it's not zero-maintenance in all scenarios -- if we want to do larger >>>> structural changes (splitting into multiple modules, reorganizing source >>>> sets), both systems would need updates. For the day-to-day reality of how >>>> the project evolves, though, the cost is very low. >>>> >>>> **The long-term path** >>>> >>>> If gradle proves itself I foresee that we eventual rely on gradle as >>>> the source of truth for builds and we update ant to delegate to gradle. If >>>> the community eventually feels that gradle is getting in our way its >>>> isolated and able to revert; so very low risk. >>>> >>>> **What's in this patch and what isn't** >>>> >>>> The patch covers the core developer loop: >>>> >>>> - Main source compilation with correct JDK flags and `--add-exports` >>>> - Dependency resolution from existing POM files >>>> - ANTLR 3 and JFlex code generation >>>> - Unit, long, burn, distributed, and simulator test suites with correct >>>> JDK-specific JVM args >>>> - All 5 test variants (compression, cdc, latest, oa, >>>> system-keyspace-directory) >>>> - Checkstyle (main + test) >>>> - Main JAR and simulator JARs >>>> - Accord composite build (no local publish step) >>>> >>>> What's not covered yet: >>>> >>>> | Category | What's Missing | >>>> |---|---| >>>> | Packaging | stress.jar, fqltool.jar, sstableloader.jar, dtest-jar, >>>> sources-jar, javadoc-jar | >>>> | Release | bin/src tarballs, checksums, dist directory assembly | >>>> | Publishing | Maven local install and remote deploy with signing | >>>> | Test suites | upgrade dtests, memory tests, >>>> stress/fqltool/sstableloader tests, CQL-specific tests | >>>> | Code coverage | JaCoCo integration | >>>> | Documentation | Javadoc, Asciidoc/Antora | >>>> | Benchmarks | JMH microbench | >>>> | Static analysis | Apache RAT license check | >>>> | Security scanning | OWASP, SonarQube | >>>> >>>> This is roughly 52% of ant's total logical outcomes. The intentional >>>> scoping choice was: cover what developers actually use daily, get buy-in on >>>> the approach, then fill in the rest. I'm happy to add any of the above -- >>>> particularly release/publishing support -- once the direction is agreed. >>>> None of these are architecturally difficult; they're just additional tasks >>>> to wire up. >>>> >>>> **Patch details** >>>> >>>> - JIRA: https://issues.apache.org/jira/browse/CASSANDRA-21344 >>>> - PR: https://github.com/apache/cassandra/pull/4778 >>>> >>>> Looking forward to feedback. >>>> >>>> --- >>>> >>>> **Prior mailing list discussions referenced:** >>>> >>>> - "[DISCUSS] Build tool" (Feb 2022) -- Aleksei Zotov's proposal to >>>> migrate from ant >>>> - "RFC try for s/ant/gradle/" (Sep 2014) -- Robert Stupp's original >>>> Gradle proposal and prototype >>>> - "[discuss] Modernization of Cassandra build system" (Jun 2015) >>>> - "[DISCUSS] CASSANDRA-17750: Security migration away from Maven Ant >>>> Tasks" (Aug 2022) >>>> - "Any plan to migrate from Ant to Maven?" (May 2020) >>>> >>>> >>>>
