Okay, these are all important clarifications in order to manage expectations etc. If formulated like that I reckon that just copying it is just fine but we probably disappoint a few folks which is part of the game I guess ...
On Tue, Jan 6, 2026 at 5:22 PM Aleksey Yeshchenko <[email protected]> wrote: > > 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 > >>>> > >>>> > >> >
