Re: Multi-module Maven projects and Scala-aware artifact IDs

> Guava has -jre > and -android flavors on their artifact ID instead of using classifiers. not exactly, they have the flavor as part of version string https://central.sonatype.com/artifact/com.google.guava/guava/32.0.1-jre/ versions which in fact looks like what François describes in another

Re: Multi-module Maven projects and Scala-aware artifact IDs

Hello Florent, i'll suggest something while I know this is not exactly what you asked for. But i'll try nevertheless, it may help :) If you could change your requirements a bit to change the *version* instead of the artifactId, then you could use the ci-friendly concept in Maven (

Re: Multi-module Maven projects and Scala-aware artifact IDs

Sure, individual projects have done things as they saw fit. Guava has -jre and -android flavors on their artifact ID instead of using classifiers. Bouncycastle is using ant for their build process. I wouldn't want to emulate either as best practice. Scala, as an ecosystem, has decided on

Re: Multi-module Maven projects and Scala-aware artifact IDs

Bouncycastle does similar, e.g. bcprov-jdk15to18-173.jar https://www.bouncycastle.org/latest_releases.html Delany On Mon, 12 Jun 2023 at 18:51, Greg Chabala wrote: > > > > Has anyone faced this before? > > > > Yes. The fact that

Re: Multi-module Maven projects and Scala-aware artifact IDs

> > Has anyone faced this before? > Yes. The fact that Scala's binary incompatibility leaked into artifact IDs rather than being a classifier irritates me still. I have no good solution for you. The mess that would have come from using Maven for cross version Scala builds led me to follow the