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