BazelJavaProtobuf依赖问题解决方法

在文章实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《Bazel Java中Protobuf依赖错误及解决方法》，聊聊，希望可以帮助到正在努力赚钱的你。

本文旨在解决Bazel Java项目中，当`java_test_suite`引用`com.google.protobuf.Timestamp`等Protobuf类型时，遇到的“Using type x from an indirect dependency”错误。核心问题在于直接依赖`proto_library`而非其对应的`java_proto_library`。教程将详细阐述如何通过定义并依赖`java_proto_library`来正确处理Protobuf Java代码的依赖关系，确保Bazel的严格依赖检查通过，并提供示例代码和注意事项。

理解Bazel严格依赖与Protobuf Java类型

在Bazel构建系统中，严格依赖（Strict Dependencies）是一项重要特性，旨在确保每个目标只直接依赖其真正需要的模块。当一个Java类（例如com.google.protobuf.Timestamp）在代码中被引用，但其提供的库并未作为直接依赖项明确声明时，Bazel就会抛出[strict] Using type X from an indirect dependency的错误。这通常意味着该类型是通过某个其他依赖项间接引入的，而Bazel要求直接使用就必须直接声明。

对于Protobuf类型，如com.google.protobuf.Timestamp，它们并非由普通的Java库直接提供，而是由.proto文件生成Java源代码后编译而成的。Protobuf的Bazel规则链通常涉及proto_library和java_proto_library。proto_library负责处理.proto文件本身及其对其他.proto文件的依赖，而java_proto_library则负责将proto_library生成的Java代码编译成可供Java项目使用的库。

当我们在java_test_suite中直接依赖@com_google_protobuf//:timestamp_proto时，实际上是依赖了一个proto_library规则。虽然这个proto_library可能在其内部间接包含了生成Java代码的逻辑或依赖，但它本身并非一个可以直接提供Java类型的Java库。因此，当测试代码尝试使用Timestamp类型时，Bazel的严格依赖检查会发现这个Java类型是间接获得的，从而触发错误。

解决方案：使用java_proto_library

解决这个问题的关键在于，为Protobuf类型生成对应的Java库，并将其作为直接依赖项添加到需要使用这些类型的Java规则中。这通过定义一个java_proto_library规则来实现。

步骤一：定义java_proto_library

首先，我们需要在BUILD文件中为@com_google_protobuf//:timestamp_proto定义一个java_proto_library规则。这个规则将负责编译timestamp_proto生成的Java代码。

# BUILD文件示例
load("@rules_java//java:defs.bzl", "java_proto_library")
load("@rules_proto//proto:defs.bzl", "proto_library") # 如果需要定义自己的proto_library

# 假设 @com_google_protobuf//:timestamp_proto 已经由WORKSPACE文件引入
# 这里我们为 timestamp_proto 定义其对应的 Java 版本
java_proto_library(
    name = "timestamp_java_proto",
    deps = ["@com_google_protobuf//:timestamp_proto"],
    # 如果 timestamp_proto 依赖其他 proto，这里也需要相应的 deps
)

在这个示例中：

• name = "timestamp_java_proto": 这是我们为生成的Java Protobuf库定义的一个新的Bazel目标名称。
• deps = ["@com_google_protobuf//:timestamp_proto"]: 这个依赖指向原始的proto_library目标，java_proto_library会基于它来生成Java代码。

步骤二：更新java_test_suite的依赖

定义了timestamp_java_proto后，我们就可以在java_test_suite中直接依赖这个新的Java Protobuf库，而不是原始的proto_library。

# 更新后的 java_test_suite 示例
load("@rules_java//java:defs.bzl", "java_test_suite")
# ... 其他 load 语句和 JUNIT5_DEPS 定义

java_test_suite(
    name = "all-tests",
    srcs = glob(["src/test/java/**/*.java"]),
    runner = "junit5",
    test_suffixes = ["Test.java"],
    runtime_deps = JUNIT5_DEPS,
    deps = [
        ":mylib",
        # 将原来的 @com_google_protobuf//:timestamp_proto 替换为我们定义的 java_proto_library
        ":timestamp_java_proto", # 引用上面定义的 Java Protobuf 库
        artifact("org.junit.jupiter:junit-jupiter-api"),
        artifact("org.junit.jupiter:junit-jupiter-params"),
    ] + deps,
)

通过这种方式，java_test_suite现在直接依赖于一个能够提供com.google.protobuf.Timestamp类的Java库，从而满足了Bazel的严格依赖要求，消除了“Using type from an indirect dependency”的错误。

注意事项与总结

1. 错误信息的误导性：有时Bazel的错误信息可能会建议添加@com_google_protobuf//:timestamp_proto到特定的Java源文件（例如//:src/test/java/com/x/CustomTest），并提供buildozer命令。然而，直接将proto_library添加到Java源文件所在的规则（如java_library或java_test）通常无法解决问题，因为proto_library本身不直接提供Java类。正确的做法是添加其对应的java_proto_library。如果buildozer命令提示“rule '...' not found”，则表明它尝试修改的不是一个Bazel规则，而是源文件路径，进一步证实了直接修改源文件依赖的思路是错误的。
2. Bazel版本与Protobuf规则：确保你的Bazel版本和rules_java、rules_proto版本兼容。Protobuf的Bazel规则可能会有更新，始终参考官方文档以获取最新和最准确的配置。
3. 通用性：这个解决方案适用于所有Protobuf生成的Java类型。无论你是在java_library、java_binary还是java_test_suite中使用Protobuf类型，都应该依赖其对应的java_proto_library。
4. 清晰的依赖图：通过明确定义java_proto_library，我们为Bazel构建系统提供了一个更清晰的依赖图。这不仅解决了当前的错误，也有助于提高构建的可靠性和可维护性。

遵循上述步骤，可以有效解决在Bazel Java项目中因Protobuf类型引起的间接依赖错误，确保构建过程的顺畅。

好了，本文到此结束，带大家了解了《BazelJavaProtobuf依赖问题解决方法》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！