Grpc-gateway: Merging two .proto files with different packages using protoc-gen-swagger throws error

[bsakweson]

I ran into an issue similar to 746,.

I have a setup with multiple micro services each defined in their own .proto file. Code generation works well until I tried to combine my openAPI documentation using protoc-gen-swagger from grpc-gateway.

Using this command protoc --proto_path=api/v1 --proto_path=$GOPATH/src --proto_path=third_party --swagger_out=logtostderr=true,allow_merge=true:third_party/OpenAPI a/a.proto b/b.proto to generate a merged apidocs.swagger.json file containing all services defined in a and b respectively so that I can serve it as a single page throws this error --swagger_out: inconsistent package names: a b. Notice that a and b are all in different packages a and b.

service a:

syntax = "proto3";

package com.somecompany.a;

option go_package = "a";

import "google/api/annotations.proto";

// A is a service for handling Foo stuff.
service A {
  // List all Foos
  //
  // Returns a (possibly paginated) list of all foo resources on success.
  rpc ListFoos (ListFoosRequest) returns (ListFoosResponse) {
    option (google.api.http) = { get: "/v1/foos" };
  }
}

// The ListFoos request message.
message ListFoosRequest {}

// The ListFoos response message.
message ListFoosResponse {}

service b:

syntax = "proto3";

package com.somecompany.b;

option go_package = "b";
import "google/api/annotations.proto";

// B is a service for handling Bar stuff.
service B {
  // List all Bars
  //
  // Returns a (possibly paginated) list of all bar resources on success.
  rpc ListBars (ListBarsRequest) returns (ListBarsResponse) {
    option (google.api.http) = { get: "/v1/bars" };
  }
}

// The ListBars request message.
message ListBarsRequest {}

// The ListBars response message.
message ListBarsResponse {}

Am I using this incorrectly? I would think that my use case is plausible since having each service in its own package helps maintained separation of concerns and keep service module smaller.

[johanbrandhorst]

Haha I already answered in #746, but to clarify, it is currently working as intended, that is not to say that we couldn't look into making this work.

I would say that it's not uncommon when existing a set of services to specify another, superset service and use that with the gateway as a simple proxy to the others.

[bsakweson]

Would you by any chance know of any hack I can use for now to get those swagger files concatenated, if so would mind sharing?

[johanbrandhorst]

I think you'd have to write a post processing tool to read both and merge the fields. There probably exists tools to do this.

[birdayz]

@bsakweson https://github.com/go-swagger/go-swagger can merge swagger files. we're using this to create one unified swagger definition.