You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 22, 2022. It is now read-only.
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
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.
The text was updated successfully, but these errors were encountered:
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 hasgrpc-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:
.proto
filesThe 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.
The text was updated successfully, but these errors were encountered: