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.
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

Reply via email to