CODEWITHSUNDEEP
protocol-buffersprotocprotobuf-java
Nikolas
Nikolas

Reputation: 2410

Wrapping and shipping the protoc, so our build environments are not required to have protoc pre-installed

In order to be able to generate classes from .proto-files, I must have the protoc installed on my system. Then I can instruct the protoc manually to compile my .proto-files. Then I might get the idea to utilize our build system for that, for example there is a maven plugin out there that does the job quite well, I would add it like so:

<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>

So each time I trigger a build, the plugin generates my classes. All good and well. But if we take a look at the plugin, it is still a hard requirement for the protoc to be installed on the system calling the build: <protocExecutable>protoc</protocExecutable>.

The question now is

In order for that to "make it work", all our developers, build systems, ... must have the very same protocol-buffers version on their system, or the generated code may vary (or even break). That also means, that as code gets older we might not be able to build it on all our build systems as the installed protoc version will be newer (well I guess you could argue to install one protoc for each version and call it with e.g. protocv3) which would require additional maintenance.

Is there something out there for the protoc like the gradle build system does with their gradlew, so basically a script that would attempt to install a specific protoc on the system that runs the build prior to calling the compiler? That way we cold store that "protow" in our VCS with the source code, just as you would do with the gradlew. Always using the "correct" protoc version for the current project?

Upvotes: 1

Views: 249

Answers (1)

Nino Walker
Nino Walker

Reputation: 2903

It's worth pointing out that the generated Java code for protobuf is also tied to a specific protobuf-java JAR version, and the binary protoc version must match that as well. So consider that in your process design.

If you can use Docker, you can use/do something like this: https://github.com/namely/docker-protoc

This solves the consistent version problem, local development, branches, etc. You could easily roll your own version of the tool referenced to suit your needs.

If this is not an option, you can consider publishing an artifact of protobufs by your build system. This solves your consistency problem, but is a challenge for local dev and branches. This is intensely dissatisfying, but works as a path of last resort.

Upvotes: 1

Related Questions