0

为了能够从 .proto 文件生成类，我必须在我的系统上安装protoc 。然后我可以手动指示 protoc 编译我的 .proto 文件。然后我可能会想到利用我们的构建系统来实现这一点，例如有一个 maven 插件可以很好地完成这项工作，我会像这样添加它：

<plugin>
    <groupId>org.xolstice.maven.plugins</groupId>
    <artifactId>protobuf-maven-plugin</artifactId>
    <version>0.5.1</version>
    <executions>
        <execution>
            <goals>
                <goal>compile</goal>
                <goal>test-compile</goal>
            </goals>
            <configuration>
                <protocExecutable>protoc</protocExecutable>
            </configuration>
        </execution>
    </executions>
</plugin>

所以每次我触发构建时，插件都会生成我的类。一切都很好。但是如果我们看一下插件，在调用 build: 的系统上安装 protoc 仍然是一个硬性要求<protocExecutable>protoc</protocExecutable>。

现在的问题是

为了让它“工作”，我们所有的开发人员、构建系统……必须在他们的系统上拥有完全相同的协议缓冲区版本，否则生成的代码可能会有所不同（甚至中断）。这也意味着，随着代码变旧，我们可能无法在所有构建系统上构建它，因为安装的 protoc 版本会更新（我猜你可能会争辩为每个版本安装一个 protoc 并使用 eg 调用它protocv3）这将需要额外的维护。

protoc 是否有一些东西，比如 gradle 构建系统对它们的gradlew, 所以基本上是一个脚本，它会尝试在调用编译器之前在运行构建的系统上安装特定的 protoc？这样我们就可以将“protow”与源代码一起冷存储在我们的 VCS 中，就像使用 gradlew 一样。总是为当前项目使用“正确”的协议版本？

4

1 回答 1

1

值得指出的是，为 protobuf 生成的 Java 代码也与特定的 protobuf-java JAR 版本相关联，并且二进制 protoc 版本也必须与之匹配。因此，请在您的流程设计中考虑这一点。

如果你可以使用 Docker，你可以使用/做这样的事情：https ://github.com/namely/docker-protoc

这解决了一致的版本问题、本地开发、分支等。您可以轻松滚动您自己的参考工具版本以满足您的需求。

如果这不是一个选项，您可以考虑通过您的构建系统发布一个 protobufs 工件。这解决了您的一致性问题，但对本地开发人员和分支机构来说是一个挑战。这是非常不满意的，但作为最后的手段。

于 2018-12-20T15:39:58.487 回答