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