> If we go by what you wrote, then what exactly is forbidding us to ditch Ant > altogether "in an hour"? It'd take at least an hour or two to review it. :)
Otherwise we should just move forward on this IMO. On Thu, May 7, 2026, at 11:48 AM, Štefan Miklošovič wrote: > Yeah, more political and social. If we go by what you wrote, then what > exactly is forbidding us to ditch Ant altogether "in an hour"? > > On Thu, May 7, 2026 at 4:04 PM Josh McKenzie <[email protected]> wrote: > > > > this delegation to Ant as a step towards full Gradle builds without Ant > > under it which might hypothetically happen in few years > > > > This is really more of a social and political issue than a technical one > > right? We have tooling that could reliably do this in under an hour at this > > point. > > > > On Tue, May 5, 2026, at 11:39 AM, Jeremiah Jordan 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) > > > > > > >
