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