...
For Xbuf and Protobof the protobuf idl (.proto) is output in the generated source folder using the model's fully name spacequalified namespace.
Generated Encoding Output
Invoking the code generator on a model outputs source for objects in a particular encoding: Json, Xbuf or Protobuf to a package that is by default defined as the model's name spacenamespace. The code generator, however, can be used to generate source to a namespace specified to the code generator. This makes it possible to generate source for mulitple multiple encodings of the same model by invoking the code generator multiple times with a separate namespace and encoding for each execution. Furthermore, it is possible to convert between any of the separate encodings by serializing/deserializing to json which is compatible between all encodings (and in the case of Xbuf/Protobuf to a binary format since the are binary compatible).
...
| Directive | Description | Default | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| generateEmbeddedEntityInterfaces | Directive indicating that the generator should create interfaces for embedded entities. This can be disabled for applications with stringent performance requirements to reduce the overhead associated with multi-morphic vtable lookups. | true | ||||||||
| generateEmbeddedEntitiesNonFinal | When this directive is set to true the generated entity class is not declared as final nor are its accessors. This feature can be useful for applications that need to mock embedded entities in test frameworks such as CGLIB, but is not recommend recommended for production use for performance reasons.
| false | ||||||||
| generateDefaultGetters | Whether or not to generate default getters that accept a value to return when the field is not set. Not typically recommended | false | ||||||||
| generateThrowOnUnsetGetters | Whether or not to generate getXXXOrThrow() or accessors that will throw an ERogFieldNotSetException when the field has not been set. This provides an alternate to calling hasXXX for a field to test if the field is unset. Usage of this directive is not recommended; hasXXX is the recommended approach to testing if a field is not set. Exception throwing is more expensive, and the generated getXXXOrThrow method introduces extra invocation overhead and a larger code size. | false | ||||||||
| generateRequiredFieldValidators | Whether or not validation logic is generated in the types validators for required fields. Enabling this leads large generated code size, and validation checks are expensive, so this is not recommended for performance sensitive applications. | false | ||||||||
| generateFluentSetters | Directive indicating that fluent style setters should be generated for fields. This can be enabled to generate fluent accessors on generated types. This can be useful for writing concise testcode, but is more overhead, so it's usage is not typically recommended. | false | ||||||||
generateAllStringsPoolable | Directive indicating that all Strings fields in the model should be generated as poolable types regardless of the value of the field's poolable attribute. | false | ||||||||
| pooledStringFieldTypeNameSuffixPolicy | Can specify None, Always or OnConflict to instruct the code generator as to how to handle naming conflicts that arise from a pooled string field type name generated from a field name are suffixed to avoid a name clash. | "None" | ||||||||
| pooledStringFieldTypeNameSuffix | Specifies the suffic to use to resolve pooled string type name conflicts with Always or OnConflict suffixing policies. | "String" |
...
| Anchor | ||||
|---|---|---|---|---|
|
To handle multi-module and multi-project builds, the ADM XML Parser, and Maven Build plugin search for model imports on the classpath using the imported model's fully qualified namespace. The model xml (and .proto for Xbuf/Protobuf) will be copied to the generated source folder in fully qualified form. To allow other models to resolve the model being generated from their classpath, users should ensure that these files are copied to the target classes folder.
| Status | ||||
|---|---|---|---|---|
|
ADM Code Generator Maven plugin will copy these files by default to target classes folder , and include them into project artifact's jar.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<!-- Method #1: (recommended) Import from relative model namespace. Imports from classpath relative to namespace of importing model, in this case some.model.namespace. This would try resolving from some/model/namespace/../../other_model/namespace/other_model.xml. Evaluating ../.. would give us resource some/other_model/namespace/other_model.xml --> <import model="../../other_model/namespace/other_model.xml" /> <!-- Method #2 (recommended): Import from full model namespace. This will work if generated sources are compiled and added to classpath. For example if we have project dependencies where one project imports a model XML from another project, the original XML file is not available, but the one in the produced jar is. Therefore, we are getting file from classpath, where project dependency containing import is added to the classpath. For maven this also works within the same project if code generation for imported other_model.xml is run first. So, when we reach in pom the code generation of model.xml, other_model.xml is already generated and xml is copied to target/classes/some/other_model/namespace/other_model.xml. target/classes is already in classpath so this will resolve successfully to other_model.xml--> <import model="some/other_model/namespace/other_model.xml" /> |
Reason The reason why this works is because the result of running code generation would be:
...
| IDL | Full Path | Description |
|---|---|---|
| descriptor.proto | google\/protobuf\/descriptor.proto | Defines options available in Protobuf |
| AdmTypes.proto | com\/neeve\/adm\/types\/protobuf\/AdmTypes.proto | Defines custom enum options and additional ADM data types |
...
The incremental code generation works by tracking above given changes in an xml file which may be found in output dir. The file has a name with a pattern like this:
.${model_filename}.xml_${md5checksum}.metadata. model_name is the name of the model file for which code was generated. md5checksum is a signature calculated from input options given to code generator, so that if any of them changes, the resulting filename no longer represents same code generation. Stored in this file are input options given to code generator and list of models with a number that would be different every time model file is persisted to disk. These files do not go into the jar, and may be deleted at any time (which they usually do when a clean build is triggered).
...