public static final class PluginProtos.CodeGeneratorResponse.File.Builder extends GeneratedMessage.Builder<PluginProtos.CodeGeneratorResponse.File.Builder> implements PluginProtos.CodeGeneratorResponse.FileOrBuilder
google.protobuf.compiler.CodeGeneratorResponse.File
Represents a single generated file.
addRepeatedField, clearField, clearOneof, clone, getAllFields, getField, getFieldBuilder, getOneofFieldDescriptor, getParentForChildren, getRepeatedField, getRepeatedFieldBuilder, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof, internalGetMapField, internalGetMutableMapField, isClean, markClean, mergeUnknownFields, newBuilderForField, onBuilt, onChanged, parseUnknownField, setField, setRepeatedField, setUnknownFieldsfindInitializationErrors, getInitializationErrorString, mergeDelimitedFrom, mergeDelimitedFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, newUninitializedMessageException, toStringaddAll, newUninitializedMessageExceptionequals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, waitfindInitializationErrors, getAllFields, getField, getInitializationErrorString, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneofpublic static final Descriptors.Descriptor getDescriptor()
protected GeneratedMessage.FieldAccessorTable internalGetFieldAccessorTable()
GeneratedMessage.BuilderinternalGetFieldAccessorTable in class GeneratedMessage.Builder<PluginProtos.CodeGeneratorResponse.File.Builder>public PluginProtos.CodeGeneratorResponse.File.Builder clear()
GeneratedMessage.Builderclear in interface Message.Builderclear in interface MessageLite.Builderclear in class GeneratedMessage.Builder<PluginProtos.CodeGeneratorResponse.File.Builder>public Descriptors.Descriptor getDescriptorForType()
Message.BuilderMessageOrBuilder.getDescriptorForType().getDescriptorForType in interface Message.BuildergetDescriptorForType in interface MessageOrBuildergetDescriptorForType in class GeneratedMessage.Builder<PluginProtos.CodeGeneratorResponse.File.Builder>public PluginProtos.CodeGeneratorResponse.File getDefaultInstanceForType()
MessageLiteOrBuildergetDefaultInstance() 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.getDefaultInstanceForType in interface MessageLiteOrBuildergetDefaultInstanceForType in interface MessageOrBuilderpublic PluginProtos.CodeGeneratorResponse.File build()
MessageLite.Builderbuild in interface Message.Builderbuild in interface MessageLite.Builderpublic PluginProtos.CodeGeneratorResponse.File buildPartial()
MessageLite.BuilderMessageLite.Builder.build(), but does not throw an exception if the message
is missing required fields. Instead, a partial message is returned.
Subsequent changes to the Builder will not affect the returned message.buildPartial in interface Message.BuilderbuildPartial in interface MessageLite.Builderpublic PluginProtos.CodeGeneratorResponse.File.Builder mergeFrom(Message other)
Message.Builderother 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:other,
then other's value overwrites the value in this message.other,
it is merged into the corresponding sub-message of this message
using the same merging rules.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++.mergeFrom in interface Message.BuildermergeFrom in class AbstractMessage.Builder<PluginProtos.CodeGeneratorResponse.File.Builder>public PluginProtos.CodeGeneratorResponse.File.Builder mergeFrom(PluginProtos.CodeGeneratorResponse.File other)
public final boolean isInitialized()
MessageLiteOrBuilderisInitialized in interface MessageLiteOrBuilderisInitialized in class GeneratedMessage.Builder<PluginProtos.CodeGeneratorResponse.File.Builder>public PluginProtos.CodeGeneratorResponse.File.Builder mergeFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry) throws IOException
MessageLite.BuilderMessageLite.Builder.mergeFrom(CodedInputStream), but also
parses extensions. The extensions that you want to be able to parse
must be registered in extensionRegistry. Extensions not in
the registry will be treated as unknown fields.mergeFrom in interface Message.BuildermergeFrom in interface MessageLite.BuildermergeFrom in class AbstractMessage.Builder<PluginProtos.CodeGeneratorResponse.File.Builder>IOExceptionpublic boolean hasName()
optional string name = 1;
The file name, relative to the output directory. The name must not contain "." or ".." components and must be relative, not be absolute (so, the file cannot lie outside the output directory). "/" must be used as the path separator, not "\". If the name is omitted, the content will be appended to the previous file. This allows the generator to break large files into small chunks, and allows the generated text to be streamed back to protoc so that large files need not reside completely in memory at one time. Note that as of this writing protoc does not optimize for this -- it will read the entire CodeGeneratorResponse before writing files to disk.
hasName in interface PluginProtos.CodeGeneratorResponse.FileOrBuilderpublic String getName()
optional string name = 1;
The file name, relative to the output directory. The name must not contain "." or ".." components and must be relative, not be absolute (so, the file cannot lie outside the output directory). "/" must be used as the path separator, not "\". If the name is omitted, the content will be appended to the previous file. This allows the generator to break large files into small chunks, and allows the generated text to be streamed back to protoc so that large files need not reside completely in memory at one time. Note that as of this writing protoc does not optimize for this -- it will read the entire CodeGeneratorResponse before writing files to disk.
getName in interface PluginProtos.CodeGeneratorResponse.FileOrBuilderpublic ByteString getNameBytes()
optional string name = 1;
The file name, relative to the output directory. The name must not contain "." or ".." components and must be relative, not be absolute (so, the file cannot lie outside the output directory). "/" must be used as the path separator, not "\". If the name is omitted, the content will be appended to the previous file. This allows the generator to break large files into small chunks, and allows the generated text to be streamed back to protoc so that large files need not reside completely in memory at one time. Note that as of this writing protoc does not optimize for this -- it will read the entire CodeGeneratorResponse before writing files to disk.
getNameBytes in interface PluginProtos.CodeGeneratorResponse.FileOrBuilderpublic PluginProtos.CodeGeneratorResponse.File.Builder setName(String value)
optional string name = 1;
The file name, relative to the output directory. The name must not contain "." or ".." components and must be relative, not be absolute (so, the file cannot lie outside the output directory). "/" must be used as the path separator, not "\". If the name is omitted, the content will be appended to the previous file. This allows the generator to break large files into small chunks, and allows the generated text to be streamed back to protoc so that large files need not reside completely in memory at one time. Note that as of this writing protoc does not optimize for this -- it will read the entire CodeGeneratorResponse before writing files to disk.
public PluginProtos.CodeGeneratorResponse.File.Builder clearName()
optional string name = 1;
The file name, relative to the output directory. The name must not contain "." or ".." components and must be relative, not be absolute (so, the file cannot lie outside the output directory). "/" must be used as the path separator, not "\". If the name is omitted, the content will be appended to the previous file. This allows the generator to break large files into small chunks, and allows the generated text to be streamed back to protoc so that large files need not reside completely in memory at one time. Note that as of this writing protoc does not optimize for this -- it will read the entire CodeGeneratorResponse before writing files to disk.
public PluginProtos.CodeGeneratorResponse.File.Builder setNameBytes(ByteString value)
optional string name = 1;
The file name, relative to the output directory. The name must not contain "." or ".." components and must be relative, not be absolute (so, the file cannot lie outside the output directory). "/" must be used as the path separator, not "\". If the name is omitted, the content will be appended to the previous file. This allows the generator to break large files into small chunks, and allows the generated text to be streamed back to protoc so that large files need not reside completely in memory at one time. Note that as of this writing protoc does not optimize for this -- it will read the entire CodeGeneratorResponse before writing files to disk.
public boolean hasInsertionPoint()
optional string insertion_point = 2;
If non-empty, indicates that the named file should already exist, and the content here is to be inserted into that file at a defined insertion point. This feature allows a code generator to extend the output produced by another code generator. The original generator may provide insertion points by placing special annotations in the file that look like: @@protoc_insertion_point(NAME) The annotation can have arbitrary text before and after it on the line, which allows it to be placed in a comment. NAME should be replaced with an identifier naming the point -- this is what other generators will use as the insertion_point. Code inserted at this point will be placed immediately above the line containing the insertion point (thus multiple insertions to the same point will come out in the order they were added). The double-@ is intended to make it unlikely that the generated code could contain things that look like insertion points by accident. For example, the C++ code generator places the following line in the .pb.h files that it generates: // @@protoc_insertion_point(namespace_scope) This line appears within the scope of the file's package namespace, but outside of any particular class. Another plugin can then specify the insertion_point "namespace_scope" to generate additional classes or other declarations that should be placed in this scope. Note that if the line containing the insertion point begins with whitespace, the same whitespace will be added to every line of the inserted text. This is useful for languages like Python, where indentation matters. In these languages, the insertion point comment should be indented the same amount as any inserted code will need to be in order to work correctly in that context. The code generator that generates the initial file and the one which inserts into it must both run as part of a single invocation of protoc. Code generators are executed in the order in which they appear on the command line. If |insertion_point| is present, |name| must also be present.
hasInsertionPoint in interface PluginProtos.CodeGeneratorResponse.FileOrBuilderpublic String getInsertionPoint()
optional string insertion_point = 2;
If non-empty, indicates that the named file should already exist, and the content here is to be inserted into that file at a defined insertion point. This feature allows a code generator to extend the output produced by another code generator. The original generator may provide insertion points by placing special annotations in the file that look like: @@protoc_insertion_point(NAME) The annotation can have arbitrary text before and after it on the line, which allows it to be placed in a comment. NAME should be replaced with an identifier naming the point -- this is what other generators will use as the insertion_point. Code inserted at this point will be placed immediately above the line containing the insertion point (thus multiple insertions to the same point will come out in the order they were added). The double-@ is intended to make it unlikely that the generated code could contain things that look like insertion points by accident. For example, the C++ code generator places the following line in the .pb.h files that it generates: // @@protoc_insertion_point(namespace_scope) This line appears within the scope of the file's package namespace, but outside of any particular class. Another plugin can then specify the insertion_point "namespace_scope" to generate additional classes or other declarations that should be placed in this scope. Note that if the line containing the insertion point begins with whitespace, the same whitespace will be added to every line of the inserted text. This is useful for languages like Python, where indentation matters. In these languages, the insertion point comment should be indented the same amount as any inserted code will need to be in order to work correctly in that context. The code generator that generates the initial file and the one which inserts into it must both run as part of a single invocation of protoc. Code generators are executed in the order in which they appear on the command line. If |insertion_point| is present, |name| must also be present.
getInsertionPoint in interface PluginProtos.CodeGeneratorResponse.FileOrBuilderpublic ByteString getInsertionPointBytes()
optional string insertion_point = 2;
If non-empty, indicates that the named file should already exist, and the content here is to be inserted into that file at a defined insertion point. This feature allows a code generator to extend the output produced by another code generator. The original generator may provide insertion points by placing special annotations in the file that look like: @@protoc_insertion_point(NAME) The annotation can have arbitrary text before and after it on the line, which allows it to be placed in a comment. NAME should be replaced with an identifier naming the point -- this is what other generators will use as the insertion_point. Code inserted at this point will be placed immediately above the line containing the insertion point (thus multiple insertions to the same point will come out in the order they were added). The double-@ is intended to make it unlikely that the generated code could contain things that look like insertion points by accident. For example, the C++ code generator places the following line in the .pb.h files that it generates: // @@protoc_insertion_point(namespace_scope) This line appears within the scope of the file's package namespace, but outside of any particular class. Another plugin can then specify the insertion_point "namespace_scope" to generate additional classes or other declarations that should be placed in this scope. Note that if the line containing the insertion point begins with whitespace, the same whitespace will be added to every line of the inserted text. This is useful for languages like Python, where indentation matters. In these languages, the insertion point comment should be indented the same amount as any inserted code will need to be in order to work correctly in that context. The code generator that generates the initial file and the one which inserts into it must both run as part of a single invocation of protoc. Code generators are executed in the order in which they appear on the command line. If |insertion_point| is present, |name| must also be present.
getInsertionPointBytes in interface PluginProtos.CodeGeneratorResponse.FileOrBuilderpublic PluginProtos.CodeGeneratorResponse.File.Builder setInsertionPoint(String value)
optional string insertion_point = 2;
If non-empty, indicates that the named file should already exist, and the content here is to be inserted into that file at a defined insertion point. This feature allows a code generator to extend the output produced by another code generator. The original generator may provide insertion points by placing special annotations in the file that look like: @@protoc_insertion_point(NAME) The annotation can have arbitrary text before and after it on the line, which allows it to be placed in a comment. NAME should be replaced with an identifier naming the point -- this is what other generators will use as the insertion_point. Code inserted at this point will be placed immediately above the line containing the insertion point (thus multiple insertions to the same point will come out in the order they were added). The double-@ is intended to make it unlikely that the generated code could contain things that look like insertion points by accident. For example, the C++ code generator places the following line in the .pb.h files that it generates: // @@protoc_insertion_point(namespace_scope) This line appears within the scope of the file's package namespace, but outside of any particular class. Another plugin can then specify the insertion_point "namespace_scope" to generate additional classes or other declarations that should be placed in this scope. Note that if the line containing the insertion point begins with whitespace, the same whitespace will be added to every line of the inserted text. This is useful for languages like Python, where indentation matters. In these languages, the insertion point comment should be indented the same amount as any inserted code will need to be in order to work correctly in that context. The code generator that generates the initial file and the one which inserts into it must both run as part of a single invocation of protoc. Code generators are executed in the order in which they appear on the command line. If |insertion_point| is present, |name| must also be present.
public PluginProtos.CodeGeneratorResponse.File.Builder clearInsertionPoint()
optional string insertion_point = 2;
If non-empty, indicates that the named file should already exist, and the content here is to be inserted into that file at a defined insertion point. This feature allows a code generator to extend the output produced by another code generator. The original generator may provide insertion points by placing special annotations in the file that look like: @@protoc_insertion_point(NAME) The annotation can have arbitrary text before and after it on the line, which allows it to be placed in a comment. NAME should be replaced with an identifier naming the point -- this is what other generators will use as the insertion_point. Code inserted at this point will be placed immediately above the line containing the insertion point (thus multiple insertions to the same point will come out in the order they were added). The double-@ is intended to make it unlikely that the generated code could contain things that look like insertion points by accident. For example, the C++ code generator places the following line in the .pb.h files that it generates: // @@protoc_insertion_point(namespace_scope) This line appears within the scope of the file's package namespace, but outside of any particular class. Another plugin can then specify the insertion_point "namespace_scope" to generate additional classes or other declarations that should be placed in this scope. Note that if the line containing the insertion point begins with whitespace, the same whitespace will be added to every line of the inserted text. This is useful for languages like Python, where indentation matters. In these languages, the insertion point comment should be indented the same amount as any inserted code will need to be in order to work correctly in that context. The code generator that generates the initial file and the one which inserts into it must both run as part of a single invocation of protoc. Code generators are executed in the order in which they appear on the command line. If |insertion_point| is present, |name| must also be present.
public PluginProtos.CodeGeneratorResponse.File.Builder setInsertionPointBytes(ByteString value)
optional string insertion_point = 2;
If non-empty, indicates that the named file should already exist, and the content here is to be inserted into that file at a defined insertion point. This feature allows a code generator to extend the output produced by another code generator. The original generator may provide insertion points by placing special annotations in the file that look like: @@protoc_insertion_point(NAME) The annotation can have arbitrary text before and after it on the line, which allows it to be placed in a comment. NAME should be replaced with an identifier naming the point -- this is what other generators will use as the insertion_point. Code inserted at this point will be placed immediately above the line containing the insertion point (thus multiple insertions to the same point will come out in the order they were added). The double-@ is intended to make it unlikely that the generated code could contain things that look like insertion points by accident. For example, the C++ code generator places the following line in the .pb.h files that it generates: // @@protoc_insertion_point(namespace_scope) This line appears within the scope of the file's package namespace, but outside of any particular class. Another plugin can then specify the insertion_point "namespace_scope" to generate additional classes or other declarations that should be placed in this scope. Note that if the line containing the insertion point begins with whitespace, the same whitespace will be added to every line of the inserted text. This is useful for languages like Python, where indentation matters. In these languages, the insertion point comment should be indented the same amount as any inserted code will need to be in order to work correctly in that context. The code generator that generates the initial file and the one which inserts into it must both run as part of a single invocation of protoc. Code generators are executed in the order in which they appear on the command line. If |insertion_point| is present, |name| must also be present.
public boolean hasContent()
optional string content = 15;
The file contents.
hasContent in interface PluginProtos.CodeGeneratorResponse.FileOrBuilderpublic String getContent()
optional string content = 15;
The file contents.
getContent in interface PluginProtos.CodeGeneratorResponse.FileOrBuilderpublic ByteString getContentBytes()
optional string content = 15;
The file contents.
getContentBytes in interface PluginProtos.CodeGeneratorResponse.FileOrBuilderpublic PluginProtos.CodeGeneratorResponse.File.Builder setContent(String value)
optional string content = 15;
The file contents.
public PluginProtos.CodeGeneratorResponse.File.Builder clearContent()
optional string content = 15;
The file contents.
public PluginProtos.CodeGeneratorResponse.File.Builder setContentBytes(ByteString value)
optional string content = 15;
The file contents.
Copyright © 2008–2016 Google. All rights reserved.