> you, Stefan and others also agreed jamm being in-tree is probably the way to > go? (Got a bit confused by the latest response, so I am clarifying) I believe so, yes. For participants on the dev list discussions in the past we have a clear suparmajority in favor of bringing it in-tree and a consensus to continue to cut a separate release artifact of the library separate from Cassandra.
On Sat, Jul 4, 2026, at 7:30 PM, Ekaterina Dimitrova wrote: > I kind of feel people would always have the approach “if it ain’t broke…” but > that is a different topic :-) > > Josh, to confirm, you, Stefan and others also agreed jamm being in-tree is > probably the way to go? (Got a bit confused by the latest response, so I am > clarifying) > > On Sat, 4 Jul 2026 at 19:03, Josh McKenzie <[email protected]> wrote: >> __ >> Somewhat ironically, having it embedded in the Apache Foundation inside a >> seemingly unrelated project with a lot of active committers may make it >> easier for others to contribute to and depend upon. Having clear governance >> on a project and a broader community supporting it should be a win here (no >> slight against Jonathan or original authors - it's just hard to develop >> cycles to supporting a project and reviewing PR's etc if it does what you >> need it to already. "If it ain't broke...") >> >> On Fri, Jul 3, 2026, at 9:51 PM, Ekaterina Dimitrova wrote: >>> +1 on being in-tree. Most of the time we update it with jdk updates or if >>> there is a bug. It just belongs to Cassandra IMHO. Otherwise it will be >>> just in another repo and there is no point moving from one to another IMHO. >>> >>> On Thu, 11 Jun 2026 at 10:57, Štefan Miklošovič <[email protected]> >>> wrote: >>>> On Thu, Jun 11, 2026 at 6:51 PM Josh McKenzie <[email protected]> wrote: >>>> > >>>> > But if you want to have Jamm directly in Cassandra repository to have >>>> > it "closer" to the codebase without a need to release it, then we >>>> > would need to put it into Cassandra repo directly. >>>> > >>>> > Being able to modify and test C* in a single IDE with jamm is a big win >>>> > for low friction iteration. If we embed jamm into cassandra-ecosystem, >>>> > workflows to work on both in tandem become much more involved. Adding >>>> > cassandra-ecosystem as a submodule to C* to get tightly coupled work on >>>> > jamm would be where things felt Very Wrong to me. >>>> >>>> Yes, I agree with this. I am aware of the fact that having it in-tree >>>> would be way more comfortable. I also think that cassandra-ecosystem >>>> as a submodule to C* is a bad idea. >>>> >>>> > Since C* is the only thing in our ecosystem that I know of that depends >>>> > on jamm, and C* is at the root of our dependency graph in our ecosystem, >>>> > putting jamm there makes sense to me. >>>> >>>> Fine. >>>> >>>> > If it was put directly in-tree then its reusing would be way more >>>> > involved. >>>> > >>>> > Why? Couldn't we just have a different build target and keep jamm >>>> > isolated? It can have its own release cycle and proper maven artifact >>>> > even if it's living inside C* can't it? >>>> >>>> Alright, fair enough. >>>> >>>> BTW, do you want to bring Jamm in-tree only into trunk? Or any other >>>> branches? >>>> >>>> > >>>> > On Thu, Jun 11, 2026, at 12:41 PM, Štefan Miklošovič wrote: >>>> > >>>> > Jamm can be in cassandra-ecosystem as another Gradle project, no? >>>> > Converting it should not be a big deal. Then Analytics and Sidecar can >>>> > be released together and Jamm would have its own release cycle. The >>>> > fact that all these projects live in one repository does not >>>> > necessarily mean that we would need to release them all at once. >>>> > >>>> > Cassandra would depend on Jamm, true, but it would not depend on >>>> > cassandra-ecosystem _git repository_. It would depend on Jamm as a >>>> > Maven dependency. >>>> > >>>> > Hence, I do not look at your "but then core C* depending on jamm in >>>> > the other repo" as problematic. So what? >>>> > >>>> > But if you want to have Jamm directly in Cassandra repository to have >>>> > it "closer" to the codebase without a need to release it, then we >>>> > would need to put it into Cassandra repo directly. >>>> > >>>> > One small advantage of having Jamm as a standalone project with its >>>> > own release cycle and having it as a proper Maven artifact is that >>>> > third parties could also depend on it as on any other artifact. If it >>>> > was put directly in-tree then its reusing would be way more involved. >>>> > >>>> > On Thu, Jun 11, 2026 at 1:37 PM Josh McKenzie <[email protected]> >>>> > wrote: >>>> > > >>>> > > Do you contemplate moving it to cassandra-ecosystem? That's >>>> > > technically also an option. >>>> > > >>>> > > I almost mentioned that but it muddies the waters when it comes to >>>> > > dependency direction from a repository perspective. Sidecar depending >>>> > > on core C*, but then core C* depending on jamm in the other repo. >>>> > > >>>> > > Given they're "repo-level" dependencies and not circular dependencies >>>> > > in the absolute code/artifact sense I don't hate it. Ultimately a >>>> > > "cleaner" end-state would be a C* monorepo that had everything in it >>>> > > since it'd be trivial to factor out shared dependencies and build from >>>> > > .class source, but that magnifies all the struggles (collision, >>>> > > migration, build systems, etc) significantly and is too much to bite >>>> > > off at first, assuming we even all agreed we should pursue it (for the >>>> > > record: I don't have a settled perspective on that). >>>> > > >>>> > > So yeah. I'd be good bringing that in to cassandra-ecosystem. In >>>> > > theory we could have cassandra-ecosystem as a submodule in core C* so >>>> > > we could pin a SHA of jamm to depend on. Kind of makes me wary / feels >>>> > > confusing since it really gives off "circular dependency" vibes even >>>> > > if it's just, again, at repo level and not projects. It would make it >>>> > > much simpler to make changes to jamm and C* in conjunction and push >>>> > > dual PR's together though, and the easier it is for us to maintain and >>>> > > extend jamm the more likely we are to do so. >>>> > > >>>> > > On Thu, Jun 11, 2026, at 2:31 AM, Štefan Miklošovič wrote: >>>> > > >>>> > > After 6 months we were discussing it, the original Jamm repository did >>>> > > not receive a single commit. Last time I wrote: >>>> > > >>>> > > "I can hardly imagine other people forking it / resurrecting it, if >>>> > > that was true it would have happened already." >>>> > > >>>> > > and it seems it still holds. The only people who forked it in the last >>>> > > 2 years was you who put Java 21 support on top and two other people >>>> > > who did not add anything to it (1) >>>> > > >>>> > > Let's move it in-tree ... >>>> > > >>>> > > Do you contemplate moving it to cassandra-ecosystem? That's >>>> > > technically also an option. >>>> > > >>>> > > (1) >>>> > > https://github.com/jbellis/jamm/forks?include=active&page=1&period=2y&sort_by=stargazer_counts >>>> > > >>>> > > On Wed, Jun 10, 2026 at 8:54 PM Josh McKenzie <[email protected]> >>>> > > wrote: >>>> > > > >>>> > > > Necro-thread powers activate! >>>> > > > >>>> > > > Since I'm on the topic (cassandra-ecosystem thread, CEP to draft on >>>> > > > that front) I figured I'd poke my head back in to this thread. I >>>> > > > think we have a general consensus here (i.e. supermajority, not >>>> > > > unanimous, but no binding -1's) on bringing this in-tree and locking >>>> > > > / deprecating the other jamm repo. >>>> > > > >>>> > > > To put a bow on it - does this track? Anyone had a change of heart >>>> > > > since we last talked through this? >>>> > > > >>>> > > > On Wed, Jan 14, 2026, at 8:14 AM, Štefan Miklošovič wrote: >>>> > > > >>>> > > > Realistically speaking if we just copy it and let the original >>>> > > > library >>>> > > > there sitting still it will just die, it is dead pretty much already. >>>> > > > It is just that we are the ones who happen to have the biggest urge >>>> > > > to >>>> > > > do something about that and have enough manpower to pull it off. I >>>> > > > can >>>> > > > hardly imagine other people forking it / resurrecting it, if that was >>>> > > > true it would have happened already. >>>> > > > >>>> > > > On Wed, Jan 14, 2026 at 8:47 AM Benjamin Lerer <[email protected]> >>>> > > > wrote: >>>> > > > > >>>> > > > > I have some mixed feelings because on one side I can understand >>>> > > > > the will to simplify our life but on the other hand I find it a >>>> > > > > bit selfish to ignore the other Jamm users. >>>> > > > > >>>> > > > > Le jeu. 8 janv. 2026 à 19:28, Josh McKenzie <[email protected]> >>>> > > > > a écrit : >>>> > > > >> >>>> > > > >> We can expect jamm changes to be mostly about supporting new >>>> > > > >> JDK's given the trajectory of the past half decade or so. Given >>>> > > > >> our intent to allow running on the latest LTS JDK across all GA >>>> > > > >> branches, that means we can expect to need to backport jamm >>>> > > > >> changes to all branches to support a new JDK. >>>> > > > >> >>>> > > > >> To Aleksey's point, however, this is something we're used to. And >>>> > > > >> with jamm the scale of the changes should be modest and the >>>> > > > >> frequency of these changes low. >>>> > > > >> >>>> > > > >> I think having the code in-tree per-branch gives us an optimal >>>> > > > >> balance of ease-of-use with our build ecosystem that we use daily >>>> > > > >> at the expense of slightly more toil on modifying jamm very >>>> > > > >> infrequently. >>>> > > > >> >>>> > > > >> On Thu, Jan 8, 2026, at 11:23 AM, Aleksey Yeshchenko wrote: >>>> > > > >> >>>> > > > >> Sure, but that is true about absolute majority of C* codebase. >>>> > > > >> Most of our utility classes are the same in most branches, >>>> > > > >> without changing that much. It’s not a reason enough to pull >>>> > > > >> everything into a submodule. >>>> > > > >> >>>> > > > >> At the end of the day I would rather deal with plain old C* repo >>>> > > > >> branches, then the combination of jamm repo branches, plus a >>>> > > > >> submodule, plus pointers to different jamm branches in C* >>>> > > > >> branches. >>>> > > > >> >>>> > > > >> Forward merging and backward-porting code is something we are >>>> > > > >> pretty good at. >>>> > > > >> >>>> > > > >> On 7 Jan 2026, at 20:16, Doug Rohrer <[email protected]> wrote: >>>> > > > >> >>>> > > > >> The last part here is a really good point. Given it'll be >>>> > > > >> something that we need in multiple branches, using a submodule >>>> > > > >> may well be the better option. >>>> > > > >> >>>> > > > >> Copy/paste of changes across several Cassandra branches is, as we >>>> > > > >> all know, pretty painful. >>>> > > > >> >>>> > > > >> Doug >>>> > > > >> >>>> > > > >> On Jan 7, 2026, at 7:38 AM, Mick <[email protected]> wrote: >>>> > > > >> >>>> > > > >> >>>> > > > >> >>>> > > > >> On 6 Jan 2026, at 18:12, Josh McKenzie <[email protected]> >>>> > > > >> wrote: >>>> > > > >> >>>> > > > >> While your solution is the easiest one, undeniably, of course, it >>>> > > > >> seems to disregard the existing user base. Some of them are other >>>> > > > >> Apache projects too. I think that we are beyond this and we want >>>> > > > >> to >>>> > > > >> have it re-usable by other projects too. >>>> > > > >> >>>> > > > >> >>>> > > > >> Right now we're a pure consumer of the lib. If we brought it >>>> > > > >> in-tree and published artifacts from our source, we'd be becoming >>>> > > > >> maintainers of the lib which is a Big Change. >>>> > > > >> >>>> > > > >> I don't think we're ready to sign up for that tbh and I'm weakly >>>> > > > >> against it. >>>> > > > >> >>>> > > > >> So that leaves a) copying code in-tree, or b) submodule. >>>> > > > >> >>>> > > > >> >>>> > > > >> >>>> > > > >> >>>> > > > >> Right, if we're not taking over jamm then we're not needing to >>>> > > > >> maintain it as a separate code repo. (I didn't realise this was >>>> > > > >> the intention either.) >>>> > > > >> >>>> > > > >> Aside from that, a git submodule does have a benefit due to how >>>> > > > >> we can change the branch of it we use and how we need to do that >>>> > > > >> we it comes time to back-porting jdk support to earlier versions. >>>> > > > >> I don't have an opinion here, it's just another point of >>>> > > > >> consideration. >>>> > > > >> >>>> > > > >> >>>> > > > >>>> > > > >>>> > > >>>> > > >>>> > >>>> > >>
