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.
