> If you have a Java project, you do not set a Scala version. Why would you?
There are 2 cases here. If you have a Java project that already has existing Scala dependencies (either directly or indirectly) in which case you have a Java project that defines a Scala version and the suffix we are talking about points to that Scala version (the reason why the suffix exists in the first place is to prevent mixing of binary incompatible Scala versions). The other case is a pure Java library that happens to want to include kafka core directly, in which case we are talking about the difference of org.apache.kafka:kafka:<VERSION> vs org.apache.kafka:kafka_2.13:<VERSION> Is this change really worth it just to save going from kafka_2.13 to kafka? As you said in the KIP we are just going to support a single Scala version so the user doesn't even need to care/know about Scala 2.13. If we are talking about the source release/docker/containers then the artifact name is completely irrelevant either way. > The streams module does not depend on the core module either, see: > https://mvnrepository.com/artifact/org.apache.kafka/kafka-streams/3.4.0 So it appears that the require query from the old https://mvnrepository.com <https://mvnrepository.com/artifact/org.apache.kafka/kafka-streams/3.4.0> site is bringing in all dependencies from all scopes (such as test) rather than just direct compile scope however this is still going to cause resolution issues for a lot of upstream projects (which use kafka core for testing as an example). If on the other hand you say that Scala is just an implementation detail of kafka core and there isn't anything of value in the ecosystem having a compile time dependency on kafka core, then which hypothetical users are we talking about that are currently having such big issues with the Scala suffixes in the artifact? If most of the users using kafka core are doing so to run kafka as an application then they are going to be using the source distribution (or some other method, i.e. docker/testcontainers etc etc) in which case the artifact names are completely irrelevant here. Either there are a significant portion of users that (for some reason) have a dependency on kafka core in which case the problems I prescribed before apply or we have a case where almost nothing depends on kafka core which means that the KIP's value is questionable while also creating a highly unorthodox situation of an artifact depending on Scala but not having a Scala suffix (which is an expectation for any artifact using Scala, implementation detail or not). On Sat, Mar 18, 2023 at 11:10 PM Ismael Juma <ism...@juma.me.uk> wrote: > Hi Matthew, > > Comments below. > > On Sat, Mar 18, 2023 at 2:27 PM Matthew Benedict de Detrich > <matthew.dedetr...@aiven.io.invalid> wrote: > > > >1. The kafka module does not expose a public api (unlike kafka-clients > or > > streams-scala) and the usage of Scala (including the version) is an > > implementation detail. > > > > This is irrelevant, the core problem is bringing in scala-library.jar and > > potentially mixing in different binary incompatible versions. > > > > I disagree. > > > > > 2. The vast majority of kafka users do not use Scala and the Scala > suffix > > is a problem for them. For example, they may depend on kafka_2.12 and > then > > that stops working when support for Scala 2.12 goes away. > > > > I fail to see how this is a "problem". All of the common JVM build tools > > already handle this transparently. You pick a Scala version, define it in > > the build tool and then everything is handled for you. If you pick the > > wrong Scala version then it will fail to resolve at which point you have > > feedback thay you picked the wrong version. > > > > If you have a Java project, you do not set a Scala version. Why would you? > > This suggestion would mean that if a user brings in Scala version X (from > > some other dependency) that differs from Kafkas version they will get a > > very hard to diagnose runtime error. > > > > > That's incorrect. kafka-clients is a pure Java library, does not > include > > the Scala suffix and does not depend on the kafka (aka core) jar. > > > > I am talking about clients of kafka such as streams which depend on core. > > In fact if you look at the direct dependencies of kafka core (see > > https://mvnrepository.com/artifact/org.apache.kafka/kafka/usages) you > will > > see there are a lot of libraries/runtimes which depends on kafka core. > > > The streams module does not depend on the core module either, see: > > https://mvnrepository.com/artifact/org.apache.kafka/kafka-streams/3.4.0 > > Ismael > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* matthew.dedetr...@aiven.io
