On Fri, Aug 26, 2016 at 7:51 AM, Mario Steinhoff <steinhoff.ma...@gmail.com>

> Currently, I am not distributing the proto file but compile the proto
> file into Java classes and create a JAR file in the service A build.
> The JAR file gets publishes to my internal artifact repository but
> without grpc-stub and grpc-protobuf transitive dependencies
> (compileOnly). The calling service includes gRPC and the jar file with
> the compile classes and then creates a ManagedChannel and a stub for
> the xxxGrpc service.

That's fine and a supported use-case. I would include real deps (not just
compileOnly) on grpc-stub and grpc-protobuf, but to each his own. As long
as service A is using the same grpc version or newer there shouldn't be
issues. Note that if your protos are reusable in other services/consumers
you should ship at least .protos so that your consumers can make their own
protos that include yours (this uses a *protobuf* dependency in Gradle).

Another way I could think of is to put the proto file into a JAR file
> and add the JAR file to dependencies in all calling services. Then I'd
> have to compile protobuf classes in each calling service but the gRPC
> versions in both services are fully independent.

That's also fine and a supported use-case. I sort of expect more people to
do this (at least Maven and Gradle users, because of the plugins), just
because it is probably a bit easier for them.

Shipping protos works better when dealing with multiple languages. Shipping
generated code for many languages takes some effort, and I'd really only
expect it for large shops providing many services to many consumers (...
like Google :) ).

You can also include both the generated code and the .protos in the same
JAR and let the consumer decide whether they want to run protoc. This also
makes developing with the Gradle plugin quite natural, since any *compile*
dependency naturally works for both Java and .proto (protos in the project
can include dependencies, but the dependencies aren't re-codegen'd). This
is what we will be doing
at Google for our public artifacts.

You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to