Our main priority is to ship Apache Cassandra and closely related projects.
We are not adopting/taking over jamm, the project, it’s not our mandate to do so. We are just inlining the dependency for internal use, primarily to simplify JDK support and deprecation across different branches of Cassandra. Tight coupling is the explicit purpose here. Other folks are free to keep using existing jamm artifacts and repo as they see fit, or fork it, or inline it if their license allows them to. > On 6 Jan 2026, at 16:58, Štefan Miklošovič <[email protected]> wrote: > > On Tue, Jan 6, 2026 at 3:49 PM Aleksey Yeshchenko <[email protected]> wrote: >> >> I would still prefer to just copy the relevant files in-tree, under current >> package name or o.a.cassandra.somewhere, and call it a day. >> >> We don’t need it to produce a separate artifact. > > Don't we? Couple replies back there was a discussion about still > having this digestible by other projects and redirecting it to our > Apache coordinates. > > 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. > > If this is not the case then of course we can just copy it. My > contribution to this discussion was made in the context of the > opposite. > > We just want to inline this dependency so that it’s no longer a 3rd > party dependency at all. Be able to have different versions of this > code in different C* branches, to better deal with jdk upgrades and > deprecation. >> >> Please don’t overcomplicate this. This is too tiny to warrant a submodule. >> >>> On 6 Jan 2026, at 14:56, Štefan Miklošovič <[email protected]> wrote: >>> >>> I would be for 1) where 2) is just a beneficial consequence of doing >>> so. 1) is the fastest way to be done with it, most bang for the buck. >>> >>> Also, 1) does not exclude 3) down the road, it just streamlines it >>> more comfortably. Accord is on Gradle already, we first quickly >>> introduce Jamm as another one, being it Maven ... whatever. But the >>> goal is completed, right? >>> >>> Then when 3) is due we might just rewrite Jamm on Maven to Gradle and >>> after doing so I can imagine that converting submodules (which are on >>> Gradle already) to one uber Gradle build is _way more easier_ than >>> trying to do it at the same time. >>> >>> On Tue, Jan 6, 2026 at 2:48 PM Josh McKenzie <[email protected]> wrote: >>>> >>>> So: >>>> - Non-controversial / roughest workflow: take it in as a submodule. Make a >>>> case for build system changes separately if at all. Continue to bend ant >>>> to our will - against its will. >>>> - Mid-controversial / smoother workflow: take in as submodule, shift build >>>> system to something modern w/better support. >>>> - Most controversial / smoothest workflow: take jamm in natively and take >>>> on a new build system piece with it (maven which it has, or migrate to >>>> gradle which would be new) >>>> >>>> I'm actually willing to make the case for the 3rd option; let me follow up >>>> with Bernardo today since he drove a lot of prep work on that front and >>>> I'll bring it to the list here on a new thread referencing this. >>>> Worst-case the build system discussion hits a rapid clear wall and we >>>> decouple the topics, get jamm as a submodule, and hash through the build >>>> system discussion separately. >>>> >>>> On Tue, Jan 6, 2026, at 9:13 AM, Brandon Williams wrote: >>>> >>>> On Tue, Jan 6, 2026 at 8:09 AM Štefan Miklošovič <[email protected]> >>>> wrote: >>>>> However, I would like to eventually see that the build systems converge >>>>> and we could rewrite >>>>> it later on to Gradle to copy how Accord has it. >>>> >>>> Changing build systems has been a non-starter for many years now, so >>>> my hope is we make some kind of incremental progress like this and >>>> reach a point where we finally take the plunge and transition fully to >>>> one build system. Either because it makes sense or out of frustration >>>> with dealing with all of them. >>>> >>>> Kind Regards, >>>> Brandon >>>> >>>> >>
