> 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
