Sets the Java package where classes generated from this .proto will be placed. By default, the proto package is used, but this is often inappropriate because proto packages do not normally start with backwards domain names.
If set, all the classes from the .proto file are wrapped in a single outer class with the given name. This applies to both Proto1 (equivalent to the old "--one_java_file" option) and Proto2 (where a .proto always translates to a single class, but you may want to explicitly choose the class name).
If set true, then the Java code generator will generate a separate .java file for each top-level message, enum, and service defined in the .proto file. Thus, these types will *not* be nested inside the outer class named by java_outer_classname. However, the outer class will still be generated to contain the file's getDescriptor() method as well as any top-level extensions defined in the file.
This option does nothing.
If set true, then the Java2 code generator will generate code that throws an exception whenever an attempt is made to assign a non-UTF-8 byte sequence to a string field. Message reflection will do the same. However, an extension field still accepts non-UTF-8 byte sequences. This option has no effect on when used with the lite runtime.
Sets the Go package where structs generated from this .proto will be placed. If omitted, the Go package will be derived from the following:
Should generic services be generated in each language? "Generic" services are not specific to any particular RPC system. They are generated by the main code generators in each language (without additional plugins). Generic services were the only kind of service generation supported by early versions of google.protobuf. Generic services are now considered deprecated in favor of using plugins that generate code specific to your particular RPC system. Therefore, these default to false. Old code which depends on generic services should explicitly set them to true.
Is this file deprecated? Depending on the target platform, this can emit Deprecated annotations for everything in the file, or it will be completely ignored; in the very least, this is a formalization for deprecating files.
Enables the use of arenas for the proto messages in this file. This applies only to generated classes for C++.
Sets the objective c class prefix which is prepended to all objective c generated classes from this .proto. There is no default.
Namespace for generated classes; defaults to the package.
By default Swift generators will take the proto package and CamelCase it replacing '.' with underscore and use that to prefix the types/symbols defined. When this options is provided, they will use this value instead to prefix the types/symbols defined.
Sets the php class prefix which is prepended to all php generated classes from this .proto. Default is empty.
Use this option to change the namespace of php generated classes. Default is empty. When this option is empty, the package name will be used for determining the namespace.
Use this option to change the namespace of php generated metadata classes. Default is empty. When this option is empty, the proto file name will be used for determining the namespace.
Use this option to change the package of ruby generated classes. Default is empty. When this option is not set, the package name will be used for determining the ruby package.
The parser stores options it doesn't recognize here. See the documentation for the "Options" section above.
Enables the use of arenas for the proto messages in this file.
Enables the use of arenas for the proto messages in this file. This applies only to generated classes for C++.
Should generic services be generated in each language? "Generic" services are not specific to any particular RPC system.
Should generic services be generated in each language? "Generic" services are not specific to any particular RPC system. They are generated by the main code generators in each language (without additional plugins). Generic services were the only kind of service generation supported by early versions of google.protobuf. Generic services are now considered deprecated in favor of using plugins that generate code specific to your particular RPC system. Therefore, these default to false. Old code which depends on generic services should explicitly set them to true.
Namespace for generated classes; defaults to the package.
Is this file deprecated? Depending on the target platform, this can emit Deprecated annotations for everything in the file, or it will be completely ignored; in the very least, this is a formalization for deprecating files.
Sets the Go package where structs generated from this .proto will be placed.
Sets the Go package where structs generated from this .proto will be placed. If omitted, the Go package will be derived from the following:
If set true, then the Java code generator will generate a separate .java file for each top-level message, enum, and service defined in the .proto file.
If set true, then the Java code generator will generate a separate .java file for each top-level message, enum, and service defined in the .proto file. Thus, these types will *not* be nested inside the outer class named by java_outer_classname. However, the outer class will still be generated to contain the file's getDescriptor() method as well as any top-level extensions defined in the file.
If set, all the classes from the .proto file are wrapped in a single outer class with the given name.
If set, all the classes from the .proto file are wrapped in a single outer class with the given name. This applies to both Proto1 (equivalent to the old "--one_java_file" option) and Proto2 (where a .proto always translates to a single class, but you may want to explicitly choose the class name).
Sets the Java package where classes generated from this .proto will be placed.
Sets the Java package where classes generated from this .proto will be placed. By default, the proto package is used, but this is often inappropriate because proto packages do not normally start with backwards domain names.
If set true, then the Java2 code generator will generate code that throws an exception whenever an attempt is made to assign a non-UTF-8 byte sequence to a string field.
If set true, then the Java2 code generator will generate code that throws an exception whenever an attempt is made to assign a non-UTF-8 byte sequence to a string field. Message reflection will do the same. However, an extension field still accepts non-UTF-8 byte sequences. This option has no effect on when used with the lite runtime.
Sets the objective c class prefix which is prepended to all objective c generated classes from this .proto.
Sets the objective c class prefix which is prepended to all objective c generated classes from this .proto. There is no default.
Sets the php class prefix which is prepended to all php generated classes from this .proto.
Sets the php class prefix which is prepended to all php generated classes from this .proto. Default is empty.
Use this option to change the namespace of php generated metadata classes.
Use this option to change the namespace of php generated metadata classes. Default is empty. When this option is empty, the proto file name will be used for determining the namespace.
Use this option to change the namespace of php generated classes.
Use this option to change the namespace of php generated classes. Default is empty. When this option is empty, the package name will be used for determining the namespace.
Use this option to change the package of ruby generated classes.
Use this option to change the package of ruby generated classes. Default is empty. When this option is not set, the package name will be used for determining the ruby package.
By default Swift generators will take the proto package and CamelCase it replacing '.' with underscore and use that to prefix the types/symbols defined.
By default Swift generators will take the proto package and CamelCase it replacing '.' with underscore and use that to prefix the types/symbols defined. When this options is provided, they will use this value instead to prefix the types/symbols defined.
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.
The parser stores options it doesn't recognize here.
The parser stores options it doesn't recognize here. See the documentation for the "Options" section above.
(Since version 0.6.0) Use toPMessage
(Since version 0.6.0) Use getField that accepts a ScalaPB descriptor and returns PValue
This option does nothing.
This option does nothing.
(Since version ) Marked as deprecated in proto file
Sets the Java package where classes generated from this .proto will be placed. By default, the proto package is used, but this is often inappropriate because proto packages do not normally start with backwards domain names.
If set, all the classes from the .proto file are wrapped in a single outer class with the given name. This applies to both Proto1 (equivalent to the old "--one_java_file" option) and Proto2 (where a .proto always translates to a single class, but you may want to explicitly choose the class name).
If set true, then the Java code generator will generate a separate .java file for each top-level message, enum, and service defined in the .proto file. Thus, these types will *not* be nested inside the outer class named by java_outer_classname. However, the outer class will still be generated to contain the file's getDescriptor() method as well as any top-level extensions defined in the file.
This option does nothing.
If set true, then the Java2 code generator will generate code that throws an exception whenever an attempt is made to assign a non-UTF-8 byte sequence to a string field. Message reflection will do the same. However, an extension field still accepts non-UTF-8 byte sequences. This option has no effect on when used with the lite runtime.
Sets the Go package where structs generated from this .proto will be placed. If omitted, the Go package will be derived from the following:
Should generic services be generated in each language? "Generic" services are not specific to any particular RPC system. They are generated by the main code generators in each language (without additional plugins). Generic services were the only kind of service generation supported by early versions of google.protobuf. Generic services are now considered deprecated in favor of using plugins that generate code specific to your particular RPC system. Therefore, these default to false. Old code which depends on generic services should explicitly set them to true.
Is this file deprecated? Depending on the target platform, this can emit Deprecated annotations for everything in the file, or it will be completely ignored; in the very least, this is a formalization for deprecating files.
Enables the use of arenas for the proto messages in this file. This applies only to generated classes for C++.
Sets the objective c class prefix which is prepended to all objective c generated classes from this .proto. There is no default.
Namespace for generated classes; defaults to the package.
By default Swift generators will take the proto package and CamelCase it replacing '.' with underscore and use that to prefix the types/symbols defined. When this options is provided, they will use this value instead to prefix the types/symbols defined.
Sets the php class prefix which is prepended to all php generated classes from this .proto. Default is empty.
Use this option to change the namespace of php generated classes. Default is empty. When this option is empty, the package name will be used for determining the namespace.
Use this option to change the namespace of php generated metadata classes. Default is empty. When this option is empty, the proto file name will be used for determining the namespace.
Use this option to change the package of ruby generated classes. Default is empty. When this option is not set, the package name will be used for determining the ruby package.
The parser stores options it doesn't recognize here. See the documentation for the "Options" section above.