Decouple Kotlin compiler from Kotlin rules

[comius]

trafficstars

Move Kotlin specific targets (like kt_jvm_import) from BUILD.com_github_jetbrains_kotlin to //kotlin/compiler.

This will make it possible to release kotlin-compiler module on bazel-central-registry without depending on rules_kotlin. The release will contain the new form BUILD.com_github_jetbrains_kotlin which doesn't depend on rules_kotlin.

RELNOTES[INC]: This breaks users that depend on @com_github_jetbrains_kotlin//:* targets. The same targets can be found under @io_bazel_rules_kotlin//kotlin/compiler:*.

It's not possible to add an alias to @com_github_jetbrains_kotlin repository, becuase it would already create a dependency on rules_kotlin repository in the bzlmod world.

Technically it's possible to release 2 bzlmod modules that have a circular dependency. But this might create some unexpected problems. It addition it would be harder to convince com_github_jetbrains_kotlin owners to depend on rules_kotlin.

Works toward: https://github.com/bazelbuild/rules_kotlin/issues/660

[comius]

I see 2 options, I think are slightly better than current state (java_import in compiler repo and kt_jvm_import in //kotlin/compiler package):

1. Don't deprecate and only use java_import rules in compiler repo (remove //kotlin/compiler package). This is less work for the users, removes cyclic module dependency (adds a dep to rules_java to Kotlin compiler, but that's not a problem). Does Kotlin setup work well with java_import?
2. Deprecate using alias instead of java_import. This wouldn't add rules_java dependency to Kotlin compiler module. For alias to work in bzlmod we'd still need to add a dep back to rules_kotlin, however we could export it to bazel-central-registry without aliases and ask users of bzlmod to depend on the new location.

Or we could also go forward with current state - export such Kotlin compiler repo and remove the deprecated targets in one of the future version of Kotlin compilers?

WDYT?

[restingbull]

I see 2 options, I think are slightly better than current state (java_import in compiler repo and kt_jvm_import in //kotlin/compiler package):

1. Don't deprecate and only use java_import rules in compiler repo (remove //kotlin/compiler package). This is less work for the users, removes cyclic module dependency (adds a dep to rules_java to Kotlin compiler, but that's not a problem). Does Kotlin setup work well with java_import?
2. Deprecate using alias instead of java_import. This wouldn't add rules_java dependency to Kotlin compiler module. For alias to work in bzlmod we'd still need to add a dep back to rules_kotlin, however we could export it to bazel-central-registry without aliases and ask users of bzlmod to depend on the new location.

Or we could also go forward with current state - export such Kotlin compiler repo and remove the deprecated targets in one of the future version of Kotlin compilers?

WDYT?

apologies, the holidays became very hectic.

1. Kotlin is completely fine with java_import. It's a selling point. The kt_jvm_import is slightly more more performant (it doesn't do any of the jvm stamping, etc.) but I think that's fine.
2. This seems more complicated than it's worth...

Over all, folk's relying on the compiler repo is actually a fairly annoying problem. For example, a lot of kotlin deps bring the jars as part of the transitive closure -- this leads to duplicated jars on the classpath, etc. etc. Ideally, we'd move to just using the maven jars, which helps solve the problem.

Let's go with 1 -- @Bencodes @nkoroste: can you verify that switching to java_import doesn't introduce undue performance regressions?

[chrislovecnm]

Any update on this?