java/maven 对生成的 (gGRPC) 代码的传递依赖

Transitive Dependencies on generated (gGRPC) code with java/maven

我们有一个 serverclient 应用程序,它们应该相互通信,都是用 java 编写并使用 maven 构建的。

它们通过 gRPC 接口进行交互。

我们在 serverclient 上有不同的依赖情况:

server                         client
  |                               |
  --> lib-a                       --> *.protobuf
  |   |
  |   --> *.protobuf
  --> lib-b
  |   |
  |   --> *.protobuf
  --> *.protobuf

server 包括库 lib-alib-b,它们又需要 子集 [=19] 中定义的消息=].服务器还需要一些来自 *.protobuf 的东西。

client 需要原始 *.protobuf 文件(不仅仅是生成的 java 源文件)以从中生成更多代码(用于叛变)。

我们的原始 *.protobuf 源代码位于单独的存储库中,现在我们需要以某种方式分发它们。其他依赖全部由maven管理(server->lib-a, server->lib-b)

我们有一些选项可以提供这种依赖性。

  1. *.protobuf 生成类文件并 将它们分发为 maven 工件
  2. 将包含 *.protobuf 的存储库作为 git-子模块

但是对于每个变体,我们都面临一些问题:

1 的问题):client 需要访问原始 *.protobuf 文件以从中生成更多内容(叛变)。有没有办法通过 Maven 分发原始文件?我还听说将生成的代码作为 maven 工件分发可能是一种不好的做法(?)

2 的问题):我们在 lib-a 中有一个 git-子模块,它将从 *.protobuf 生成所有 *.class 文件并将这些生成的源包含在它的发布的神器。同样的事情发生在 lib-b。如果两个库都是独立发布的,它们可能会包含不同版本的生成源。当 server 包含两者时,这可能会导致问题。与 maven 管理的依赖项相比,这不是显式的,编译过程中不会有警告。此外,我们希望在我们的版本中排除 SNAPSHOT 依赖项(我们目前使用 maven-enforcer-plugin 强制执行)。是否有一些最佳实践可以通过 git-submodules 实现相同的目的(我目前最好的想法是限制 CI 管道中子模块允许的分支名称 ...)

非常感谢这里的一些建议:)

目前,我也在做自己的阅读:

Maven 和 Gradle protobuf 插件将 .proto 文件包含在与编译生成的文件 (.class) 相同的库 .jar 中。这允许依赖于单个 jar 并为 protoc 和 javac 提供资产。

我建议为您的 .proto 和相关生成的代码创建 Maven 库。将其视为普通 Java 库。