+1 (nb, but not a vote, so ¯\_(ツ)_/¯ ) - would be lovely to not have to deal with this individually for each project in which we use the in-jvm dtest framework. As Francisco noted, we’re using this in the sidecar and Analytics projects now and I’ve had to jump through a lot of hoops to get everything building consistently.
I’ve got some minor modifications to the way in which the existing shading works that I can contribute back to the core Cassandra project (mostly, a few additional relocations and not using the user’s default Maven cache as the temporary installation location as it was difficult to make sure you had the correct dtest jar with a bunch of them in the `.m2` directory). Doug > On Nov 28, 2023, at 2:51 PM, Josh McKenzie <jmcken...@apache.org> wrote: > > Building these jars every time we run every CI job is just silly. > > +1. > > On Tue, Nov 28, 2023, at 2:08 PM, Francisco Guerrero wrote: >> Hi Abe, >> >> I'm +1 on this. Several Cassandra-ecosystem projects build the dtest jar in >> CI. We'd very >> much prefer to just consumed shaded dtest jars from Cassandra releases for >> testing >> purposes. >> >> Best, >> - Francisco >> >> On 2023/11/28 19:02:17 Abe Ratnofsky wrote: >> > Hey folks - wanted to raise a separate thread to discuss publishing of >> > dtest-shaded JARs on release. >> > >> > Currently, adjacent projects that want to use the jvm-dtest framework need >> > to build the shaded JARs themselves. This is a decent amount of work, and >> > is duplicated across each project. This is mainly relevant for projects >> > like Sidecar and Driver. Currently, those projects need to clone and build >> > apache/cassandra themselves, run ant dtest-jar, and move the JAR into the >> > appropriate place. Different build systems treat local JARs differently, >> > and the whole process can be a bit complicated. Would be great to be able >> > to treat these as normal dependencies. >> > >> > https://issues.apache.org/jira/browse/CASSANDRA-19113 >> > >> > Any objections? >> > >> > -- >> > Abe
