regarmukesh3g opened a new pull request, #23373: URL: https://github.com/apache/kafka/pull/23373
[KAFKA-21011](https://issues.apache.org/jira/browse/KAFKA-21011) ## Problem The published pom for `org.apache.kafka:kafka_2.13` lists `org.apache.kafka:kafka-server` with `runtime` scope: ```xml <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-server</artifactId> <version>4.1.3</version> <scope>runtime</scope> </dependency> ``` This is because `core` declares it as an `implementation` dependency in `build.gradle`. However, `kafka.server.KafkaConfig` extends `org.apache.kafka.server.config.AbstractKafkaConfig`, which lives in the `server` module: ```scala class KafkaConfig private(doLog: Boolean, val props: util.Map[_, _], enforceProviderAllowlist: Boolean) extends AbstractKafkaConfig( ``` That supertype is therefore part of `core`'s compile-time API surface. With `kafka-server` only on the runtime classpath, a consumer that references `KafkaConfig` cannot see its supertype when compiling. The Kotlin compiler already warns about this and is moving towards rejecting it outright: ``` w: Cannot access 'org.apache.kafka.server.config.AbstractKafkaConfig' which is a supertype of 'KafkaConfig'. This may be forbidden soon. Check the module classpath for missing or conflicting dependencies. ``` Users currently have to work around it by re-declaring `kafka-server` themselves, which dependency-analysis linters then flag as an unnecessary explicit dependency. ## Fix Declare `server` as an `api` dependency of `core`, which puts `kafka-server` in `compile` scope in the generated pom. This matches the existing treatment of `clients`. The comment already sitting above that declaration records the rationale: ```gradle // `core` is often used in users' tests, define the following dependencies as `api` for backwards compatibility // even though the `core` module doesn't expose any public API api project(':clients') ``` ## Testing This is a build-configuration change, so it is verified against the generated pom rather than a unit test. There is no existing test asserting pom contents. **Generated pom before** (`./gradlew :core:generatePomFileForMavenJavaPublication`): ``` kafka-clients compile kafka-server runtime ``` **After:** ``` kafka-clients compile kafka-server compile ``` A structured comparison of the full pom confirms `kafka-server`'s scope is the only dependency change — no dependencies added or removed (25 before, 25 after). **The resolved `runtimeClasspath` of `core` is byte-identical before and after** (32 entries, `diff` clean), so this changes only the scope recorded in the published pom, not what actually ends up on the classpath. `:core:compileScala`, `:core:compileTestScala`, `:core:jar`, and the dependent modules `:tools`, `:streams` and `:connect:runtime` all compile cleanly. ### A note on the dropped exclusions Moving the dependency from `implementation` to `api` means `kafka-server` no longer carries the `javax`/`jline`/`jms`/`jmxri`/`jmxtools`/`mail` exclusions in the pom, since those are attached to the `implementation` configuration: ```gradle configurations { // manually excludes some unnecessary dependencies implementation.exclude module: 'javax' ... } ``` This is consistent with the existing `api` dependencies — `kafka-clients` and `scala-library` never carried those exclusions either. The exclusions guard against transitive dependencies of old log4j 1.x artifacts, and none of the excluded modules appear anywhere in `core`'s resolved dependency graph. This is corroborated by the unchanged `runtimeClasspath` above. I'm happy to instead promote the exclusions to a configuration that covers `api` as well, if reviewers would prefer to keep them attached defensively. ### Committer Checklist (excluded from commit message) - [ ] Verify design and implementation - [ ] Verify test coverage and CI build status - [ ] Verify documentation (including upgrade notes) 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01GvbzZgK7eH63iPswf8tV6v -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
