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