PluginProtos.CodeGeneratorRequest.Builder
Skip navigation links
  • Summary: 
  • Nested | 
  • Field | 
  • Constr | 
  • Method
  • Detail: 
  • Field | 
  • Constr | 
  • Method
com.google.protobuf.compiler

Class PluginProtos.CodeGeneratorRequest.Builder

    • Method Detail

      • getDefaultInstanceForType

        public PluginProtos.CodeGeneratorRequest getDefaultInstanceForType()
        Description copied from interface: MessageLiteOrBuilder
        Get an instance of the type with no fields set. Because no fields are set, all getters for singular fields will return default values and repeated fields will appear empty. This may or may not be a singleton. This differs from the getDefaultInstance() method of generated message classes in that this method is an abstract method of the MessageLite interface whereas getDefaultInstance() is a static method of a specific class. They return the same thing.
        Specified by:
        getDefaultInstanceForType in interface MessageLiteOrBuilder
        Specified by:
        getDefaultInstanceForType in interface MessageOrBuilder

      • mergeFrom

        public PluginProtos.CodeGeneratorRequest.Builder mergeFrom(Message other)
        Description copied from interface: Message.Builder
        Merge other into the message being built. other must have the exact same type as this (i.e. getDescriptorForType() == other.getDescriptorForType()).

        Merging occurs as follows. For each field:
        * For singular primitive fields, if the field is set in other, then other's value overwrites the value in this message.
        * For singular message fields, if the field is set in other, it is merged into the corresponding sub-message of this message using the same merging rules.
        * For repeated fields, the elements in other are concatenated with the elements in this message.
        * For oneof groups, if the other message has one of the fields set, the group of this message is cleared and replaced by the field of the other message, so that the oneof constraint is preserved.

        This is equivalent to the Message::MergeFrom method in C++.

        Specified by:
        mergeFrom in interface Message.Builder
        Overrides:
        mergeFrom in class AbstractMessage.Builder<PluginProtos.CodeGeneratorRequest.Builder>

      • getFileToGenerateList

        public ProtocolStringList getFileToGenerateList()
         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.
        repeated string file_to_generate = 1;
        Specified by:
        getFileToGenerateList in interface PluginProtos.CodeGeneratorRequestOrBuilder
        Returns:
        A list containing the fileToGenerate.

      • getFileToGenerateCount

        public int getFileToGenerateCount()
         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.
        repeated string file_to_generate = 1;
        Specified by:
        getFileToGenerateCount in interface PluginProtos.CodeGeneratorRequestOrBuilder
        Returns:
        The count of fileToGenerate.

      • getFileToGenerate

        public java.lang.String getFileToGenerate(int index)
         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.
        repeated string file_to_generate = 1;
        Specified by:
        getFileToGenerate in interface PluginProtos.CodeGeneratorRequestOrBuilder
        Parameters:
        index - The index of the element to return.
        Returns:
        The fileToGenerate at the given index.

      • getFileToGenerateBytes

        public ByteString getFileToGenerateBytes(int index)
         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.
        repeated string file_to_generate = 1;
        Specified by:
        getFileToGenerateBytes in interface PluginProtos.CodeGeneratorRequestOrBuilder
        Parameters:
        index - The index of the value to return.
        Returns:
        The bytes of the fileToGenerate at the given index.

      • setFileToGenerate

        public PluginProtos.CodeGeneratorRequest.Builder setFileToGenerate(int index,
                                                                   java.lang.String value)
         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.
        repeated string file_to_generate = 1;
        Parameters:
        index - The index to set the value at.
        value - The fileToGenerate to set.
        Returns:
        This builder for chaining.

      • addFileToGenerate

        public PluginProtos.CodeGeneratorRequest.Builder addFileToGenerate(java.lang.String value)
         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.
        repeated string file_to_generate = 1;
        Parameters:
        value - The fileToGenerate to add.
        Returns:
        This builder for chaining.

      • addAllFileToGenerate

        public PluginProtos.CodeGeneratorRequest.Builder addAllFileToGenerate(java.lang.Iterable<java.lang.String> values)
         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.
        repeated string file_to_generate = 1;
        Parameters:
        values - The fileToGenerate to add.
        Returns:
        This builder for chaining.

      • clearFileToGenerate

        public PluginProtos.CodeGeneratorRequest.Builder clearFileToGenerate()
         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.
        repeated string file_to_generate = 1;
        Returns:
        This builder for chaining.

      • addFileToGenerateBytes

        public PluginProtos.CodeGeneratorRequest.Builder addFileToGenerateBytes(ByteString value)
         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.
        repeated string file_to_generate = 1;
        Parameters:
        value - The bytes of the fileToGenerate to add.
        Returns:
        This builder for chaining.

      • setParameter

        public PluginProtos.CodeGeneratorRequest.Builder setParameter(java.lang.String value)
         The generator parameter passed on the command-line.
        optional string parameter = 2;
        Parameters:
        value - The parameter to set.
        Returns:
        This builder for chaining.

      • setParameterBytes

        public PluginProtos.CodeGeneratorRequest.Builder setParameterBytes(ByteString value)
         The generator parameter passed on the command-line.
        optional string parameter = 2;
        Parameters:
        value - The bytes for parameter to set.
        Returns:
        This builder for chaining.

      • getProtoFileList

        public java.util.List<DescriptorProtos.FileDescriptorProto> getProtoFileList()
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;
        Specified by:
        getProtoFileList in interface PluginProtos.CodeGeneratorRequestOrBuilder

      • getProtoFileCount

        public int getProtoFileCount()
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;
        Specified by:
        getProtoFileCount in interface PluginProtos.CodeGeneratorRequestOrBuilder

      • getProtoFile

        public DescriptorProtos.FileDescriptorProto getProtoFile(int index)
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;
        Specified by:
        getProtoFile in interface PluginProtos.CodeGeneratorRequestOrBuilder

      • setProtoFile

        public PluginProtos.CodeGeneratorRequest.Builder setProtoFile(int index,
                                                              DescriptorProtos.FileDescriptorProto value)
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;

      • setProtoFile

        public PluginProtos.CodeGeneratorRequest.Builder setProtoFile(int index,
                                                              DescriptorProtos.FileDescriptorProto.Builder builderForValue)
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;

      • addProtoFile

        public PluginProtos.CodeGeneratorRequest.Builder addProtoFile(DescriptorProtos.FileDescriptorProto value)
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;

      • addProtoFile

        public PluginProtos.CodeGeneratorRequest.Builder addProtoFile(int index,
                                                              DescriptorProtos.FileDescriptorProto value)
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;

      • addProtoFile

        public PluginProtos.CodeGeneratorRequest.Builder addProtoFile(DescriptorProtos.FileDescriptorProto.Builder builderForValue)
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;

      • addProtoFile

        public PluginProtos.CodeGeneratorRequest.Builder addProtoFile(int index,
                                                              DescriptorProtos.FileDescriptorProto.Builder builderForValue)
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;

      • addAllProtoFile

        public PluginProtos.CodeGeneratorRequest.Builder addAllProtoFile(java.lang.Iterable<? extends DescriptorProtos.FileDescriptorProto> values)
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;

      • clearProtoFile

        public PluginProtos.CodeGeneratorRequest.Builder clearProtoFile()
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;

      • removeProtoFile

        public PluginProtos.CodeGeneratorRequest.Builder removeProtoFile(int index)
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;

      • getProtoFileBuilder

        public DescriptorProtos.FileDescriptorProto.Builder getProtoFileBuilder(int index)
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;

      • getProtoFileOrBuilder

        public DescriptorProtos.FileDescriptorProtoOrBuilder getProtoFileOrBuilder(int index)
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;
        Specified by:
        getProtoFileOrBuilder in interface PluginProtos.CodeGeneratorRequestOrBuilder

      • getProtoFileOrBuilderList

        public java.util.List<? extends DescriptorProtos.FileDescriptorProtoOrBuilder> getProtoFileOrBuilderList()
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;
        Specified by:
        getProtoFileOrBuilderList in interface PluginProtos.CodeGeneratorRequestOrBuilder

      • addProtoFileBuilder

        public DescriptorProtos.FileDescriptorProto.Builder addProtoFileBuilder()
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;

      • addProtoFileBuilder

        public DescriptorProtos.FileDescriptorProto.Builder addProtoFileBuilder(int index)
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;

      • getProtoFileBuilderList

        public java.util.List<DescriptorProtos.FileDescriptorProto.Builder> getProtoFileBuilderList()
         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.
        repeated .google.protobuf.FileDescriptorProto proto_file = 15;

      • getCompilerVersionBuilder

        public PluginProtos.Version.Builder getCompilerVersionBuilder()
         The version number of protocol compiler.
        optional .google.protobuf.compiler.Version compiler_version = 3;
Skip navigation links
  • Summary: 
  • Nested | 
  • Field | 
  • Constr | 
  • Method
  • Detail: 
  • Field | 
  • Constr | 
  • Method