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