Is your feature request related to a problem? Please describe.
One of the biggest challenges with having .proto files as part of the codebase and including it in the build phase is the elongated build times. I have seen that the build time goes substantially high because of the protoc code generation.
The easiest way for this to be by passed is by housing the .proto files in a separate maven/gradle repository and defining the build process on that repository.
So a grpc service project would now contain two components.
grpc-proto-dependencies - which contains all the generated code and also the relevant jars needed by the generated code.grpc-service - which has grpc-proto-dependencies as a dependency and thus does away with code generation every time.
This has a lot of benefits, because now the code generation happens ONLY on a need basis rather than happening every single time (I guess we can circumvent and benefit from the incremental build nature of gradle, but not sure if its true with maven)
Describe the solution you'd like
Assuming that a project basically takes the above route of having the proto generated code available as a dependency, how can we get grpc-wiremock to work in this model ?
Currently this project works in two models:
- Directly consume the docker image and provide it with the directory that contains the
.proto files
- Follow the approach of building a custom docker image wherein the code generation has already happened and use that image for the tests (As detailed in this docker file https://github.com/Adven27/grpc-wiremock/blob/master/example/Dockerfile)
The problem with (2) is that it now means that one needs to have access to some sort of a docker registry to be able to benefit from this. This is not necessarily true with everyone or may not be an option too.
Open to figuring out how this can be done and willing to contribute to make this a reality as well.
Describe alternatives you've considered
Nothing comes to my mind yet which can be an alternative for this enhancement.
Additional context
Add any other context or screenshots about the feature request here.
Is your feature request related to a problem? Please describe.
One of the biggest challenges with having
.protofiles as part of the codebase and including it in the build phase is the elongated build times. I have seen that the build time goes substantially high because of the protoc code generation.The easiest way for this to be by passed is by housing the
.protofiles in a separate maven/gradle repository and defining the build process on that repository.So a grpc service project would now contain two components.
grpc-proto-dependencies- which contains all the generated code and also the relevant jars needed by the generated code.grpc-service- which hasgrpc-proto-dependenciesas a dependency and thus does away with code generation every time.This has a lot of benefits, because now the code generation happens ONLY on a need basis rather than happening every single time (I guess we can circumvent and benefit from the incremental build nature of gradle, but not sure if its true with maven)
Describe the solution you'd like
Assuming that a project basically takes the above route of having the proto generated code available as a dependency, how can we get
grpc-wiremockto work in this model ?Currently this project works in two models:
.protofilesThe problem with (2) is that it now means that one needs to have access to some sort of a docker registry to be able to benefit from this. This is not necessarily true with everyone or may not be an option too.
Open to figuring out how this can be done and willing to contribute to make this a reality as well.
Describe alternatives you've considered
Nothing comes to my mind yet which can be an alternative for this enhancement.
Additional context
Add any other context or screenshots about the feature request here.