com.google.protobuf.compiler.plugin
CodeGeneratorRequest
Related Docs:
object CodeGeneratorRequest
| package plugin
com.google.protobuf.compiler.plugin
The .proto files that were explicitly listed on the command-line. The code generator should generate code only for these files. Each file's descriptor will be included in proto_file, below.
The generator parameter passed on the command-line.
FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.
The version number of protocol compiler.
The version number of protocol compiler.
The .proto files that were explicitly listed on the command-line.
The .proto files that were explicitly listed on the command-line. The code generator should generate code only for these files. Each file's descriptor will be included in proto_file, below.
The generator parameter passed on the command-line.
FileDescriptorProtos for all files in files_to_generate and everything they import.
FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.
Returns a human-readable ASCII format representation of this message.
Returns a human-readable ASCII format representation of this message.
The original message can be decoded from this format by using fromAscii on the companion object.
human-readable representation of this message.
(Since version 0.6.0) Use toPMessage
(Since version 0.6.0) Use getField that accepts a ScalaPB descriptor and returns PValue
An encoded CodeGeneratorRequest is written to the plugin's stdin.
The .proto files that were explicitly listed on the command-line. The code generator should generate code only for these files. Each file's descriptor will be included in proto_file, below.
The generator parameter passed on the command-line.
FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.
The version number of protocol compiler.