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