Follow-up to #53044, which fixed the immediate V3 protobuf leak from the quarkus-grpc-protoc-plugin main artifact via shade-config (#54583). This issue tracks the longer-term refactor: replacing com.salesforce.servicelibs:jprotoc as a dependency of MutinyGrpcGenerator entirely.
Context from the #53044 discussion
jprotoc:1.2.2 (Apr 2023) is the latest release. The upstream salesforce/reactive-grpc project is paused (see salesforce/reactive-grpc#337 — the maintainer no longer has admin rights to cut releases, Salesforce has no one assigned, and the move to grpc-ecosystem stalled). A pending PR (salesforce/reactive-grpc#335 bumping to Protobuf V4) has been open since Mar 2025 without anyone able to land it. So we're effectively maintaining a dependency on a paused project pinned to a deprecated protobuf line.
@andreaTP suggested an opt-in V4 generator alongside the current one as a gentle migration path. @cescoffier scoped this to Quarkus 4 due to API surface implications.
Suggested approach
Two options on the table (per @andreaTP and the #53044 thread):
-
In-tree re-implementation. The touch-points in MutinyGrpcGenerator against jprotoc are shallow — ~5 references out of 417 LOC (extends Generator, applyTemplate, ProtocPlugin.generate/debug, ProtoTypeMap, GeneratorException); the rest only touches com.google.protobuf.DescriptorProtos. Estimated ~150-200 LOC contained in extensions/grpc/protoc/, one dep swap (jprotoc → JMustache for templating). Solves the V3 dependency at the root.
-
Opt-in V4 generator alongside the current one for a gentler migration. The existing generator keeps working for users who can't move yet; the new V4 generator becomes the default in a future major.
Happy to take this on once the timing is right. Filing the tracking issue now so the context from the #53044 thread doesn't go stale.
cc @cescoffier @andreaTP @alesj
Follow-up to #53044, which fixed the immediate V3 protobuf leak from the
quarkus-grpc-protoc-pluginmain artifact via shade-config (#54583). This issue tracks the longer-term refactor: replacingcom.salesforce.servicelibs:jprotocas a dependency ofMutinyGrpcGeneratorentirely.Context from the #53044 discussion
jprotoc:1.2.2(Apr 2023) is the latest release. The upstreamsalesforce/reactive-grpcproject is paused (see salesforce/reactive-grpc#337 — the maintainer no longer has admin rights to cut releases, Salesforce has no one assigned, and the move togrpc-ecosystemstalled). A pending PR (salesforce/reactive-grpc#335 bumping to Protobuf V4) has been open since Mar 2025 without anyone able to land it. So we're effectively maintaining a dependency on a paused project pinned to a deprecated protobuf line.@andreaTP suggested an opt-in V4 generator alongside the current one as a gentle migration path. @cescoffier scoped this to Quarkus 4 due to API surface implications.
Suggested approach
Two options on the table (per @andreaTP and the #53044 thread):
In-tree re-implementation. The touch-points in
MutinyGrpcGeneratoragainst jprotoc are shallow — ~5 references out of 417 LOC (extends Generator,applyTemplate,ProtocPlugin.generate/debug,ProtoTypeMap,GeneratorException); the rest only touchescom.google.protobuf.DescriptorProtos. Estimated ~150-200 LOC contained inextensions/grpc/protoc/, one dep swap (jprotoc→ JMustache for templating). Solves the V3 dependency at the root.Opt-in V4 generator alongside the current one for a gentler migration. The existing generator keeps working for users who can't move yet; the new V4 generator becomes the default in a future major.
Happy to take this on once the timing is right. Filing the tracking issue now so the context from the #53044 thread doesn't go stale.
cc @cescoffier @andreaTP @alesj