Yep ... political and social. Not like we could not do it, it is just that it would bring a lot of abruption.
We might say "hey, from 7.0 you are fully on Gradle so you have cca a year to prepare for this because we are not going to look back" or we can say "Look, there is also a Gradle way of doing this and we get there are people with various backgrounds so we do not want to break things for them unnecessarily but please be advised that sooner or later this is really going to happen, we just have not figured out yet when". I ultimately do not mind either way, I would just appreciate it if there was some period people can prepare for this transition, either that sitting in trunk until 7.0 in some feature branch or this way of Gradle - Ant delegation. I just feel like we should not just flip the switch "overnight" as David already put it. On Fri, May 8, 2026 at 8:46 PM David Capwell <[email protected]> wrote: > > Ant is sadly part of our public API in some sense… Tools have been built over > the years that understand how to Build Cassandra (such as CCM), and those > tools new time to deal with a breaking change such as dropping ant… So even > if we are 100% on gradle, we need ant that calls Gradle so we don’t break > those tools over night. > > On May 8, 2026, at 6:12 AM, Shailaja Koppu <[email protected]> wrote: > > +1 great initiative. > > > > On May 5, 2026, at 4:39 PM, Jeremiah Jordan <[email protected]> wrote: > > This looks like a great start at having parallel build tools. > > On May 4, 2026 at 2:26:54 PM, Štefan Miklošovič <[email protected]> > wrote: >> >> A lot to chew on! I think this is a good initiative, the hardest part >> is often to actually start and I am glad that David took the lead >> here. >> >> It would be wonderful if we succeeded to release 7.0 "the new way". >> Not everything has to be converted in order to have the most critical >> Ant targets on Gradle without any delegation. Then the rest is just a >> matter of time. >> >> I understand this delegation to Ant as a step towards full Gradle >> builds without Ant under it which might hypothetically happen in few >> years, if we agree on it, it is just that this way of doing it is the >> least disruptive and brings the most functionality from Ant to Gradle >> virtually for free. >> >> On Wed, Apr 29, 2026 at 1:23 AM David Capwell <[email protected]> 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) >> >> > >
