Rule for Kotlin JVM protobuf libraries

[SanjayVas]

protocolbuffers/protobuf#8272 added support for generating Kotlin code. It appears that it's specifically for JVM, as it depends on the Java protobuf API. This functionality does not appear to be exposed in any Bazel rules.

Following existing patterns, there should be a kt_jvm_proto_library rule akin to the java_proto_library rule from rules_java.

[cgruber]

This sounds good, but the proto rules are presently on fire, and I'm not sure they are in a stable enough place to rely on for our project. We already live on top of the java and android rules which have their own challenges. I might suggest this as a separate project, to be honest. We can revisit this once we have our toolchain situation under more control, but for now, I dont' think this is going to happen, unless someone volunteers some discussion and PRs. If folks want to open discuss design here, and plan out a PR, which someone is willing to build and propose, that would be fine. But as a simple feature request, I don't think this will get done.

[cgruber]

I'll leave the issue open (but the tag is closed) in case folks want to have a design conversation in this thread.

[cgruber]

Given it's been a few weeks, I'm going to close this. Feel free to keep the discussion going.

[SanjayVas]

the proto rules are presently on fire, and I'm not sure they are in a stable enough place to rely on for our project

Can you give more context here on what you mean?

IIUC, the primary difficulty I can think of is that the Kotlin Protobuf Documentation states that you need to specify both --java_out and --kotlin_out to protoc. This implies that you can't generate the Kotlin and Java code separately. Ideally for Bazel though, kt_jvm_proto_library should depend on a java_proto_library target so that you can avoid having multiple JARs with the same generated Java code. That said, maybe this is where Starlark Aspects come into play.

[SanjayVas]

My team ended up throwing together a kt_jvm_proto_library macro that works for our project. It probably needs some cleanup before it could be adopted into bazelbuild. We've attempted to document the bits that are particularly messy.

One additional issue is that unlike java_proto_library, it only generates the Kotlin extensions for the specified proto_library sources and not the transitive proto deps. Perhaps using aspects as mentioned above could get it to generate Kotlin extensions for transitive deps without duplication.

[SanjayVas]

For anyone curious, we updated the version of kt_jvm_proto_library in our project to use a Bazel aspect such that Kotlin extensions are generated for all transitive proto_library dependencies. This brings it more in line with how other language-specific proto library rules work. See world-federation-of-advertisers/common-jvm#66.

Note that the result is still not efficient as it could be, as you may end up with the same Kotlin class compiled into multiple JARs. This is because the aspect calls protoc to generate the Kotlin extensions, but the actual Kotlin compilation is done by a macro using a kt_jvm_library rule. This is why I believe the kt_jvm_library rule ultimately belongs in rules_kotlin, as all of the functionality for Kotlin compilation in Bazel is in this repo's internals.

[aryeh-looker]

See grpc/grpc-kotlin#290