Skip to content
This repository has been archived by the owner on Sep 22, 2022. It is now read-only.

Enable support for generated code as jars #29

Open
krmahadevan opened this issue Dec 22, 2021 · 0 comments
Open

Enable support for generated code as jars #29

krmahadevan opened this issue Dec 22, 2021 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@krmahadevan
Copy link
Contributor

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.

  1. grpc-proto-dependencies - which contains all the generated code and also the relevant jars needed by the generated code.
  2. 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:

  1. Directly consume the docker image and provide it with the directory that contains the .proto files
  2. 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.

@krmahadevan krmahadevan added the enhancement New feature or request label Dec 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants