> delays this effort for years as we need time to get people on board and used > to gradle before we flip that switch. Oof. I'm way more optimistic on this one; if we can get a PR that has ant targets as dumb wrappers that instead call gradle targets (i.e. all workflows and local scripting Just Work), I don't see why we couldn't merge that as soon as we ironed out kinks.
Is there anyone that's broadly against that approach? Or did I just misunderstand the other thread / JIRA you'd created David? On Wed, Jun 3, 2026, at 1:21 PM, David Capwell wrote: > Fair point but one thing to point out, if this work depends on gradle that > delays this effort for years as we need time to get people on board and used > to gradle before we flip that switch. So leaving in tree means we have to > hand roll all that logic in ant. > > Sent from my iPhone > >> On Jun 3, 2026, at 12:33 PM, Jon Haddad <[email protected]> wrote: >> >> Josh is right. Gradle subprojects could allow this without dealing with >> separate repo. I've done this before and am about to again for some stuff I >> maintain. I spent a long time agonozing over this for my other projects and >> found it works exceptionally well, especially bc you frequently develop >> things that are tightly coupled. >> >> Juggling repos sucks, this solves it (imo) perfectly. >> >> Jon >> >> On Tue, Jun 2, 2026 at 1:18 PM Josh McKenzie <[email protected]> wrote: >>> __ >>>> Is there a reason not to use a folder in the current repo that becomes its >>>> own jar? It can even be published separately if we like? >>> >>>> Mostly to decouple from Cassandra release. >>> I *think* we could just have that .jar release on its own cadence >>> independently of the parent C* project. >>> >>> Some of us have talked about taking this same approach to making some code >>> from C* available to the ecosystem (think I/O .jar that has SSTable >>> read/write, CommitLog read/write, etc). This feels like a very similarly >>> shaped thing. >>> >>> I assume w/a modern build / publish / etc system we'd be able to publish a >>> release that represents a strict subset of the parent project out of the >>> repo right? >>> >>> On Mon, Jun 1, 2026, at 8:18 PM, David Capwell wrote: >>>> Mostly to decouple from Cassandra release. If there is a feature added >>>> does it have to wait for the next major release of Cassandra so others can >>>> consume? Even if we can get to yearly releases that’s still a long wait. >>>> >>>> For example Alex and I have been talking about proper fuzz testing, so >>>> best case is a year before 3rd parties could use. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jun 1, 2026, at 4:32 PM, Jeremiah Jordan <[email protected]> wrote: >>>>> >>>>> Does it need to be a separate repo? Is there a reason not to use a folder >>>>> in the current repo that becomes its own jar? It can even be published >>>>> separately if we like? >>>>> >>>>> -Jeremiah >>>>> >>>>> On Jun 1, 2026 at 10:00:15 AM, David Capwell <[email protected]> wrote: >>>>>> Hi all, >>>>>> >>>>>> We've discussed pulling utilities out of trunk before. I'd like to >>>>>> actually start. My primary need is for test utilities so my focus is >>>>>> there. >>>>>> >>>>>> This isn't just my need. Sidecar wants property/stateful tests but can't >>>>>> use ours without a published jar. >>>>>> >>>>>> Proposed approach: >>>>>> >>>>>> 1. Define scope — start with property/stateful test utilities >>>>>> 2. Set up the repo and release independently of Cassandra >>>>>> 3. ... >>>>>> 4. Cassandra depends on the library >>>>>> >>>>>> I'd focus on the fork first, before making Cassandra depend on it — >>>>>> keeps our builds simple and gives the lib room to stabilize. We can sort >>>>>> out the dependency question later (wait on releases, or use submodules?). >>>>>> >>>>>> Happy to drive this if there's interest. >>>>>> >>>>>> Sent from my iPhone >>>
