Skip to content

compiler/generator: declare kotlinx-coroutines-core JVM variant#756

Open
smolkaj wants to merge 1 commit into
grpc:masterfrom
smolkaj:generator-coroutines-jvm
Open

compiler/generator: declare kotlinx-coroutines-core JVM variant#756
smolkaj wants to merge 1 commit into
grpc:masterfrom
smolkaj:generator-coroutines-jvm

Conversation

@smolkaj

@smolkaj smolkaj commented Apr 11, 2026

Copy link
Copy Markdown

compiler/.../generator declares the common kotlinx-coroutines-core artifact, but the Kotlin source resolves to the JVM variant on the classpath, so rules_kotlin's experimental_strict_kotlin_deps = "error" fails:

** Please add the following dependencies:
@…grpc_kotlin_maven//:org_jetbrains_kotlinx_kotlinx_coroutines_core_jvm
to //compiler/src/main/java/io/grpc/kotlin/generator:generator

Switch to the -jvm variant. No behavior change (the JVM always resolves to this artifact for this package); the :stub and :context targets already declare both variants, so only :generator needed a fix.

Downstream consumers of grpc-kotlin that enable strict-deps currently have to patch this locally. Fixing it upstream removes that friction.

Not in this PR: a separate strict-deps issue in the kt_jvm_grpc_library macro in kt_jvm_grpc.bzl (the generated kt_jvm_library doesn't directly declare @grpc-java//api, kotlinx-coroutines-core-jvm, or the user's java_proto_library). Happy to send a follow-up — the fix is a bit more opinionated so I wanted to keep this PR trivially mergeable.

The `generator` kt_jvm_library declares the common
`kotlinx-coroutines-core` Maven artifact, but its Kotlin source uses
symbols that live in the JVM-specific `kotlinx-coroutines-core-jvm`
artifact. Under rules_kotlin's `experimental_strict_kotlin_deps`
checker, the build fails with:

    ** Please add the following dependencies:
    @rules_jvm_external++maven+grpc_kotlin_maven//:
        org_jetbrains_kotlinx_kotlinx_coroutines_core_jvm
    to //compiler/src/main/java/io/grpc/kotlin/generator:generator

Switching to the `-jvm` variant matches where the symbols actually
resolve on the JVM classpath and unblocks strict-deps consumers.

No behavior change — the `-jvm` artifact is always what the JVM
resolves for this package.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>
smolkaj added a commit to 4ward-p4/4ward that referenced this pull request Apr 11, 2026
grpc/grpc-kotlin#756 covers the
generator/BUILD.bazel half. The kt_jvm_grpc.bzl macro half is more
opinionated and may need a separate conversation upstream before it
can land.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant