Kosh, you mean mvn and not gradle? There was a PR to move to gradle that was not committed, as far as I recall.
Indeed, I hope everyone has a nice holiday season :-) I am not sure modules vs in-tree. Probably someone has to play a bit with it to provide the pros and cons here? (If it was not already done) Best regards, Ekaterina On Mon, 29 Dec 2025 at 16:34, Mick <[email protected]> wrote: > 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. > >> >> > >> > > >> > >> > > > >
