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: 1. 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) 2. 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. > >> > > > >
