public static final class PluginProtos.CodeGeneratorResponse.File.Builder extends GeneratedMessageV3.Builder<PluginProtos.CodeGeneratorResponse.File.Builder> implements PluginProtos.CodeGeneratorResponse.FileOrBuilder
Represents a single generated file.
Protobuf type google.protobuf.compiler.CodeGeneratorResponse.File
Inheritance
Object > AbstractMessageLite.Builder<MessageType,BuilderType> > AbstractMessage.Builder<BuilderType> > GeneratedMessageV3.Builder > PluginProtos.CodeGeneratorResponse.File.BuilderStatic Methods
getDescriptor()
public static final Descriptors.Descriptor getDescriptor()
Returns | |
---|---|
Type | Description |
Descriptors.Descriptor |
Methods
addRepeatedField(Descriptors.FieldDescriptor field, Object value)
public PluginProtos.CodeGeneratorResponse.File.Builder addRepeatedField(Descriptors.FieldDescriptor field, Object value)
Parameters | |
---|---|
Name | Description |
field |
Descriptors.FieldDescriptor |
value |
Object |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
build()
public PluginProtos.CodeGeneratorResponse.File build()
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File |
buildPartial()
public PluginProtos.CodeGeneratorResponse.File buildPartial()
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File |
clear()
public PluginProtos.CodeGeneratorResponse.File.Builder clear()
Called by the initialization and clear code paths to allow subclasses to reset any of their builtin fields back to the initial values.
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
clearContent()
public PluginProtos.CodeGeneratorResponse.File.Builder clearContent()
The file contents.
optional string content = 15;
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
This builder for chaining. |
clearField(Descriptors.FieldDescriptor field)
public PluginProtos.CodeGeneratorResponse.File.Builder clearField(Descriptors.FieldDescriptor field)
Parameter | |
---|---|
Name | Description |
field |
Descriptors.FieldDescriptor |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
clearGeneratedCodeInfo()
public PluginProtos.CodeGeneratorResponse.File.Builder clearGeneratedCodeInfo()
Information describing the file content being inserted. If an insertion point is used, this information will be appropriately offset and inserted into the code generation metadata for the generated files.
optional .google.protobuf.GeneratedCodeInfo generated_code_info = 16;
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
clearInsertionPoint()
public PluginProtos.CodeGeneratorResponse.File.Builder clearInsertionPoint()
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.
optional string insertion_point = 2;
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
This builder for chaining. |
clearName()
public PluginProtos.CodeGeneratorResponse.File.Builder clearName()
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.
optional string name = 1;
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
This builder for chaining. |
clearOneof(Descriptors.OneofDescriptor oneof)
public PluginProtos.CodeGeneratorResponse.File.Builder clearOneof(Descriptors.OneofDescriptor oneof)
TODO(jieluo): Clear it when all subclasses have implemented this method.
Parameter | |
---|---|
Name | Description |
oneof |
Descriptors.OneofDescriptor |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
clone()
public PluginProtos.CodeGeneratorResponse.File.Builder clone()
Clones the Builder.
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
getContent()
public String getContent()
The file contents.
optional string content = 15;
Returns | |
---|---|
Type | Description |
String |
The content. |
getContentBytes()
public ByteString getContentBytes()
The file contents.
optional string content = 15;
Returns | |
---|---|
Type | Description |
ByteString |
The bytes for content. |
getDefaultInstanceForType()
public PluginProtos.CodeGeneratorResponse.File getDefaultInstanceForType()
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.
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File |
getDescriptorForType()
public Descriptors.Descriptor getDescriptorForType()
Get the message's type's descriptor. This differs from the getDescriptor()
method of
generated message classes in that this method is an abstract method of the Message
interface whereas getDescriptor()
is a static method of a specific class. They return
the same thing.
Returns | |
---|---|
Type | Description |
Descriptors.Descriptor |
getGeneratedCodeInfo()
public DescriptorProtos.GeneratedCodeInfo getGeneratedCodeInfo()
Information describing the file content being inserted. If an insertion point is used, this information will be appropriately offset and inserted into the code generation metadata for the generated files.
optional .google.protobuf.GeneratedCodeInfo generated_code_info = 16;
Returns | |
---|---|
Type | Description |
DescriptorProtos.GeneratedCodeInfo |
The generatedCodeInfo. |
getGeneratedCodeInfoBuilder()
public DescriptorProtos.GeneratedCodeInfo.Builder getGeneratedCodeInfoBuilder()
Information describing the file content being inserted. If an insertion point is used, this information will be appropriately offset and inserted into the code generation metadata for the generated files.
optional .google.protobuf.GeneratedCodeInfo generated_code_info = 16;
Returns | |
---|---|
Type | Description |
DescriptorProtos.GeneratedCodeInfo.Builder |
getGeneratedCodeInfoOrBuilder()
public DescriptorProtos.GeneratedCodeInfoOrBuilder getGeneratedCodeInfoOrBuilder()
Information describing the file content being inserted. If an insertion point is used, this information will be appropriately offset and inserted into the code generation metadata for the generated files.
optional .google.protobuf.GeneratedCodeInfo generated_code_info = 16;
Returns | |
---|---|
Type | Description |
DescriptorProtos.GeneratedCodeInfoOrBuilder |
getInsertionPoint()
public String getInsertionPoint()
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.
optional string insertion_point = 2;
Returns | |
---|---|
Type | Description |
String |
The insertionPoint. |
getInsertionPointBytes()
public ByteString getInsertionPointBytes()
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.
optional string insertion_point = 2;
Returns | |
---|---|
Type | Description |
ByteString |
The bytes for insertionPoint. |
getName()
public String getName()
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.
optional string name = 1;
Returns | |
---|---|
Type | Description |
String |
The name. |
getNameBytes()
public ByteString getNameBytes()
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.
optional string name = 1;
Returns | |
---|---|
Type | Description |
ByteString |
The bytes for name. |
hasContent()
public boolean hasContent()
The file contents.
optional string content = 15;
Returns | |
---|---|
Type | Description |
boolean |
Whether the content field is set. |
hasGeneratedCodeInfo()
public boolean hasGeneratedCodeInfo()
Information describing the file content being inserted. If an insertion point is used, this information will be appropriately offset and inserted into the code generation metadata for the generated files.
optional .google.protobuf.GeneratedCodeInfo generated_code_info = 16;
Returns | |
---|---|
Type | Description |
boolean |
Whether the generatedCodeInfo field is set. |
hasInsertionPoint()
public boolean hasInsertionPoint()
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.
optional string insertion_point = 2;
Returns | |
---|---|
Type | Description |
boolean |
Whether the insertionPoint field is set. |
hasName()
public boolean hasName()
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.
optional string name = 1;
Returns | |
---|---|
Type | Description |
boolean |
Whether the name field is set. |
internalGetFieldAccessorTable()
protected GeneratedMessageV3.FieldAccessorTable internalGetFieldAccessorTable()
Get the FieldAccessorTable for this type. We can't have the message class pass this in to the constructor because of bootstrapping trouble with DescriptorProtos.
Returns | |
---|---|
Type | Description |
GeneratedMessageV3.FieldAccessorTable |
isInitialized()
public final boolean isInitialized()
Returns true if all required fields in the message and all embedded messages are set, false otherwise.
Returns | |
---|---|
Type | Description |
boolean |
mergeFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry)
public PluginProtos.CodeGeneratorResponse.File.Builder mergeFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry)
Like 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.
Parameters | |
---|---|
Name | Description |
input |
CodedInputStream |
extensionRegistry |
ExtensionRegistryLite |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
Exceptions | |
---|---|
Type | Description |
IOException |
mergeFrom(Message other)
public PluginProtos.CodeGeneratorResponse.File.Builder mergeFrom(Message other)
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
, thenother
'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++.
Parameter | |
---|---|
Name | Description |
other |
Message |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
mergeFrom(PluginProtos.CodeGeneratorResponse.File other)
public PluginProtos.CodeGeneratorResponse.File.Builder mergeFrom(PluginProtos.CodeGeneratorResponse.File other)
Parameter | |
---|---|
Name | Description |
other |
PluginProtos.CodeGeneratorResponse.File |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
mergeGeneratedCodeInfo(DescriptorProtos.GeneratedCodeInfo value)
public PluginProtos.CodeGeneratorResponse.File.Builder mergeGeneratedCodeInfo(DescriptorProtos.GeneratedCodeInfo value)
Information describing the file content being inserted. If an insertion point is used, this information will be appropriately offset and inserted into the code generation metadata for the generated files.
optional .google.protobuf.GeneratedCodeInfo generated_code_info = 16;
Parameter | |
---|---|
Name | Description |
value |
DescriptorProtos.GeneratedCodeInfo |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
mergeUnknownFields(UnknownFieldSet unknownFields)
public final PluginProtos.CodeGeneratorResponse.File.Builder mergeUnknownFields(UnknownFieldSet unknownFields)
Merge some unknown fields into the UnknownFieldSet for this message.
Parameter | |
---|---|
Name | Description |
unknownFields |
UnknownFieldSet |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
setContent(String value)
public PluginProtos.CodeGeneratorResponse.File.Builder setContent(String value)
The file contents.
optional string content = 15;
Parameter | |
---|---|
Name | Description |
value |
String The content to set. |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
This builder for chaining. |
setContentBytes(ByteString value)
public PluginProtos.CodeGeneratorResponse.File.Builder setContentBytes(ByteString value)
The file contents.
optional string content = 15;
Parameter | |
---|---|
Name | Description |
value |
ByteString The bytes for content to set. |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
This builder for chaining. |
setField(Descriptors.FieldDescriptor field, Object value)
public PluginProtos.CodeGeneratorResponse.File.Builder setField(Descriptors.FieldDescriptor field, Object value)
Parameters | |
---|---|
Name | Description |
field |
Descriptors.FieldDescriptor |
value |
Object |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
setGeneratedCodeInfo(DescriptorProtos.GeneratedCodeInfo value)
public PluginProtos.CodeGeneratorResponse.File.Builder setGeneratedCodeInfo(DescriptorProtos.GeneratedCodeInfo value)
Information describing the file content being inserted. If an insertion point is used, this information will be appropriately offset and inserted into the code generation metadata for the generated files.
optional .google.protobuf.GeneratedCodeInfo generated_code_info = 16;
Parameter | |
---|---|
Name | Description |
value |
DescriptorProtos.GeneratedCodeInfo |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
setGeneratedCodeInfo(DescriptorProtos.GeneratedCodeInfo.Builder builderForValue)
public PluginProtos.CodeGeneratorResponse.File.Builder setGeneratedCodeInfo(DescriptorProtos.GeneratedCodeInfo.Builder builderForValue)
Information describing the file content being inserted. If an insertion point is used, this information will be appropriately offset and inserted into the code generation metadata for the generated files.
optional .google.protobuf.GeneratedCodeInfo generated_code_info = 16;
Parameter | |
---|---|
Name | Description |
builderForValue |
DescriptorProtos.GeneratedCodeInfo.Builder |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
setInsertionPoint(String value)
public PluginProtos.CodeGeneratorResponse.File.Builder setInsertionPoint(String value)
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.
optional string insertion_point = 2;
Parameter | |
---|---|
Name | Description |
value |
String The insertionPoint to set. |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
This builder for chaining. |
setInsertionPointBytes(ByteString value)
public PluginProtos.CodeGeneratorResponse.File.Builder setInsertionPointBytes(ByteString value)
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.
optional string insertion_point = 2;
Parameter | |
---|---|
Name | Description |
value |
ByteString The bytes for insertionPoint to set. |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
This builder for chaining. |
setName(String value)
public PluginProtos.CodeGeneratorResponse.File.Builder setName(String value)
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.
optional string name = 1;
Parameter | |
---|---|
Name | Description |
value |
String The name to set. |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
This builder for chaining. |
setNameBytes(ByteString value)
public PluginProtos.CodeGeneratorResponse.File.Builder setNameBytes(ByteString value)
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.
optional string name = 1;
Parameter | |
---|---|
Name | Description |
value |
ByteString The bytes for name to set. |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
This builder for chaining. |
setRepeatedField(Descriptors.FieldDescriptor field, int index, Object value)
public PluginProtos.CodeGeneratorResponse.File.Builder setRepeatedField(Descriptors.FieldDescriptor field, int index, Object value)
Parameters | |
---|---|
Name | Description |
field |
Descriptors.FieldDescriptor |
index |
int |
value |
Object |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |
setUnknownFields(UnknownFieldSet unknownFields)
public final PluginProtos.CodeGeneratorResponse.File.Builder setUnknownFields(UnknownFieldSet unknownFields)
Parameter | |
---|---|
Name | Description |
unknownFields |
UnknownFieldSet |
Returns | |
---|---|
Type | Description |
PluginProtos.CodeGeneratorResponse.File.Builder |