Remove explicit dependency on protobuf#221
Conversation
With `--incompatible_enable_proto_toolchain_resolution`, the root module is supposed to provide a `proto_lang_toolchain` for Java, which injects the runtime. Hardcoded dependencies on the `protobuf` module would negate the benefits of supplying a toolchain with precompiled `protoc` and runtime. Since the only used symbol from the protobuf runtime was an exception class, it has been replaced with a check for its class name. If more protobuf runtime symbols should be needed in the future, they should be obtained from a `current_java_proto_runtime` target that first looks for a `proto_lang_toolchain` for Java and only then falls back to the hardcoded reference.
|
I needed to make this change to finally remove any dependency on |
alexeagle
left a comment
alexeagle
left a comment
There was a problem hiding this comment.
Nice fix! Very interesting that users were forced to compile protobuf_java just to get a type-only symbol 😓
tetromino
left a comment
tetromino
left a comment
There was a problem hiding this comment.
Nice!
(I tried to do the same change in the legacy WORKSPACE setup - but it looks like there we still need com_google_protobuf as a transitive dep.)
|
Could you create a release with this change? Then modules in the BCR could start using it without patches. |
|
+1 on request for release, I'm running into the need to patch this out as well |
|
@tetromino ping again on a release, the last one is 309 days ago |
|
@alexeagle - I want to get #231, #232, and #216 in before cutting the release. |
|
LMK if you're interested in the techniques we use for OSS rulesets so release instructions are just "push a tag". Makes it such a non-event that you could release both before and after landing some things 😜 |
I agree it’s cool. Me and @meteorcloudy spent a couple of hours each, fixing it on Monday for a minor rules_proto release. But I really think it’s cool when it works. ;) |
|
BTW, the issue we hit for rules_proto release is bazel-contrib/.github#16, where |
|
@alexeagle - stardoc-0.7.0 has been released and is now in the central registry. Sorry for the wait!
Sure - do you have a good example in mind that Stardoc can follow? |
5 participants
With
--incompatible_enable_proto_toolchain_resolution, the root module is supposed to provide aproto_lang_toolchainfor Java, which injects the runtime. Hardcoded dependencies on theprotobufmodule would negate the benefits of supplying a toolchain with precompiledprotocand runtime.Since the only used symbol from the protobuf runtime was an exception class, it has been replaced with a check for its class name. If more protobuf runtime symbols should be needed in the future, they should be obtained from a
current_java_proto_runtimetarget that first looks for aproto_lang_toolchainfor Java and only then falls back to the hardcoded reference.The WORKSPACE deps macro still brings in
com_google_protobufas this may be the only source of the repo for users.