nscn.polaris2.protoc.bridge

Maven coordinates of an artifact a generator wants on the consumer's classpath.

crossVersion = true means the build tool should append its Scala binary version suffix to artifactId (foo -> foo_3).

A generator compiled into protoc itself (--java_out, --cpp_out, ...).

protoc's --descriptor_set_out, which writes a single file rather than a directory.

Extra environment the bridge hands to in-JVM generators, on top of what protoc sends.

protoc's plugin protocol has no room for this, so the bridge appends it as an unknown field on the serialized CodeGeneratorRequest and mirrors it in the child process environment. No Java or Scala class is generated for the message: the writer side must work without a protobuf-java of its own version on the classpath, so it serializes by hand (see ProtoUtils) and the reader side uses DynamicMessage.

Field number and variable name are deliberately kept byte-identical to protoc-bridge's (1020 is protobuf's globally reserved extension number for ScalaPB) so a third-party protoc plugin that already speaks this protocol keeps working.

Reader half of ExtraEnv, split out because it needs protobuf-java and only runs inside the generator, where a compatible protobuf-java is guaranteed.

One code generator invocation protoc should perform.

A generator running inside this JVM, reached through a frontend.PluginFrontend.

An external protoc-gen-<name> executable, optionally at an explicit path.

The few protobuf wire-format primitives the bridge needs on its own.

ExtraEnv is appended to an already-serialized CodeGeneratorRequest without ever parsing it, so the bridge cannot go through protobuf-java's generated code here - it would need a compiled message type for a message that deliberately has none.

Entry point: turns a list of Targets into a single protoc invocation.

The raw interface a protoc code generator implements: bytes of a CodeGeneratorRequest in, bytes of a CodeGeneratorResponse out.

Generator authors normally implement nscn.polaris2.protoc.bridge.codegen.CodeGenApp instead, which decodes the request into resolved FileDescriptors.

How the bridge actually launches protoc.

Abstract rather than a plain function because the build tool may want to intercept the invocation, and because the extra environment carrying the secondary-output directory has to reach the child process.

A JvmGenerator loaded from its own artifact into its own ClassLoader.

The point is dependency isolation: the build tool, and any other generator in the same protoc run, may hold an incompatible protobuf-java. Resolving the generator's artifact separately and loading it in a child loader keeps those apart.

Normalizes os.name / os.arch into the classifiers protobuf publishes its protoc executables under (osx-aarch_64, linux-x86_64, ...).

A generator plus where its output goes and which options it receives.

Ready-made Generator values for the generators protoc ships with.