gRPC code generation for specific dependencies

Description

gRPC users are encouraged to share .proto files instead of generated code, as the other way around defeats the purpose of schema first contract. Both client and server should use the same .proto file to be able to communicate.

My opinion is that the most common way of sharing .proto files is between modules in a multi-module project. In this case, Quarkus does not provide any config or way to register the .proto files for code generation or discovery.

Given the following project structure:

example-parent
|
|- example-security-api
|- example-audit-api
|- example-common-api
|- example-security-service
|- example-audit-service
|- example-service

The -api modules contain only .proto files to be used between services, because you manage your .proto files at a single place and you don’t need to copy the files from one service to another. The security service uses the same .proto files to implement the security API server part and the example service uses the same .proto files to generate the client. In this common scenario, even if you set quarkus.generate-code.grpc.scan-for-imports to all, nothing is generated. IntelliJ doesn’t even let you run the project. Please note that the service modules have no .proto files whatsoever and adding jandex index doesn’t help either. Users resort to using the generated code because copy-pasting the .proto files in the same project in multiple modules is error prone.

Quarkus should provide a way for code generation for this scenario, without sharing the actual code, but using the .proto files and it should be documented in the guides.

Implementation ideas

My proposal is to add configuration similar to quarkus.index-dependency which will run code generation on a given dependency based on the .proto files found in the dependency. This way we will avoid scanning the whole classpath and it will work for both local and remote dependencies. The configuration can also ask input from the developer for the actual path where the .proto files reside in the dependency. When specifying a dependency, version shouldn’t be provided. Maybe we can make artifactId optional too. Developer would require setting the correct configuration and making sure that the .proto files are actually packaged in the jar output for code generation to work.

[kristijan-rusu]

@michalszynkiewicz Here is simplest reproducer I could make. If you want to test the implementation with generated code, uncomment the extension and plugins part of the example-api maven pom. org.example.zip

[michalszynkiewicz]

I ended up with a solution specific to gRPC but implementing it for other providers shouldn’t be that hard now