Why not use a git submodule now that we have that mechanism in-place in-tree ?
That has my vote, as it gives us the best of both worlds: in-tree dev plus seperate repo and releases for others. > On 29 Dec 2025, at 17:38, Josh McKenzie <[email protected]> wrote: > > Hope everyone is having a good holiday season thus far. > > Seems like we have a pretty obvious consensus here and the topic's pretty > non-controversial. Best-worst-option and all that. There is a thornier > question this brings up: jamm uses gradle. C* uses ant. > > I'm curious what you all think about the following approach: > • We bring in the existing pom.xml for jamm (see: > https://github.com/jbellis/jamm/blob/master/pom.xml) and update docs for C* > repo to show how to build and test jamm. Update C* deps and pointers and all > that (as discussed loosely above in-thread) > • We a. confirm complete stability for jamm build and CI, then b. > integrate jamm building and testing into our CI pipelines > If this is non-controversial as well, we can probably move forward w/jamm > integration w/out a CEP or broader litigation of the build system. > > On Sun, Dec 14, 2025, at 12:16 PM, Michael Shuler wrote: >> >> >> +100, thanks for the big picture thoughts on rdepends and relocation - >> this is how we do things right for ours and larger community with grace. >> >> On 12/11/25 2:09 PM, Josh McKenzie wrote: >> > It appears we can publish an artifact under org.apache.* and use >> > relocation to have the existing jamm entry in maven redirect to our >> > newly published artifact should we choose to go that route. I'm not an >> > expert here and have only done a minimal amount of exploration, but that >> > should allow us to relocate the code in-tree but still publish artifacts >> > that were accessible at the previous groupId. >> > >> > https://maven.apache.org/guides/mini/guide-relocation.html <https:// >> > maven.apache.org/guides/mini/guide-relocation.html> >> > >> > >> > >> > On Wed, Dec 10, 2025, at 5:46 PM, Nate McCall wrote: >> >> These are much better data point! Thanks!! >> >> >> >> On Thu, Dec 11, 2025 at 11:42 AM Ekaterina Dimitrova >> >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> >> Another datapoint: >> >> https://mvnrepository.com/artifact/com.github.jbellis/jamm >> >> <https://mvnrepository.com/artifact/com.github.jbellis/jamm> >> >> >> >> Usages for the latest version: >> >> https://mvnrepository.com/artifact/com.github.jbellis/jamm/0.4.0/ >> >> usages <https://mvnrepository.com/artifact/com.github.jbellis/ >> >> jamm/0.4.0/usages> >> >> >> >> On Wed, 10 Dec 2025 at 17:39, Josh McKenzie <[email protected] >> >> <mailto:[email protected]>> wrote: >> >> >> >> __ >> >>> jamm seems to have a decent user base >> >> I'm looking but I don't see it; curious what makes you say >> >> this. The project hasn't had any commits since looks like >> >> 10/2023, new forks aren't being made, new issues and PR's not >> >> being opened. >> >> >> >> I definitely want us to maintain the ability to cut an >> >> isolated build, test, release cycle of jamm so anyone that / >> >> is /using it and had any interest in contributing should be >> >> able to do so with the same ease they have today. The added >> >> friction would be the small hurdle of needing to clone the C* >> >> repo instead of just jamm. >> >> >> > >> >> >
