The Talon Manual

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Command Line/AntMaven PluginDescriptionDefault
-f,
--file

modelFile

The input file specified either as OS path or URL-
-m,
--modelsdir
modelsDirectoryBase directory to use when searching for imported models that are not found on the project / generator's classpath.-
-o,
--outdir
projectOutputDirectory

Base output directory for the generated files.

For maven plugin defaults to target/generated-[test]-sources/nvx-adm

-
-c,
--classesdir
classesOutputDirectoryClasses output folder (to which generated resoures should be copied). May be specified multiple times to copy to multiple directories.-
-e,
--encoding
encodingTypeEncoding type of content underlying the generated classes (Xbuf | Protobuf | Json)Protobuf
-x,
--xpcompat
protoXbufGenerationCompatibilityWire compatibility between protobuf and xbuf generated classes (None | Xbuf | ProtobufProtobuf
-y,
--emptyifnullarray
generateArrayGetterEmptyIfNullInstructs the code generator return empty arrays instead of null for unset array fieldsfalse
-n,
--namespace
namespaceNamespace override of model parsed from the input file (overrides namespace in model file if supplied)-
-p,
--protodir
N/A

An additonal directory in which to search for imported .proto files.

-
-d,
--directive
directives

A key=value pair specifying a code generation directive. (May be specified multiple times).

See Directives below.

-
-b,
--buildinfo
buildInfoString with build-time information such as project version, timestamp or machine. This is added to the AdmGenerated annotation of generated classes.-
-i,
--incremental
incrementalBuildTrigger incremental code generation - run only if something changed since last run

false

(true for maven plugin)

N/AuseBasicDeltaDetectionWhen running an incremental build, basic delta detection indicates thatmodel'sare rebuilt based on whether source model timestamp. With advanceddeltadetection dependencies are examined as well.false
-u,
--bundledir
modelBundleOutputDirectoryDirectory to which to output model XML and IDL files if applicable-
N/AgenerateModelBundleIndicates whether models with all their dependencies and IDLs should be output to modelBundleOutputDirectoryfalse
N/AcodegenListenerClassNameClass name of external listener to receive events from code generator. See ADM Code Generation Events.-
N/AcodegenListenerPropertiesAdditional properties to pass to the constructed code gen listener.-

...

DirectiveDescriptionDefault
requireExplicitCollectionKeys

Directive indicating that map collections' contained entities must define an explicit field field to store the key for the entity when it is in the map. When this directive is false, it is possible that as the model evolves the implicitly generated key field could change and cause existing keys to be ignored on upgrade.

(lightbulb) It is recommend that new projects set this directive to true.

Status
colourGreen
titleSince 3.11

false
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 recommended for production use for performance reasons. 

Status
colourGreen
titleSince 3.8.189

false
generateDefaultGettersWhether or not to generate default getters that accept a value to return when the field is not set. Not typically recommendedfalse
generateThrowOnUnsetGettersWhether or not to generate getXXXOrThrow() or accessors that will throw an ERogFieldNotSetException when the field has not been set. This provides an alternative 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
generateRequiredFieldValidatorsWhether 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
generateFluentSettersDirective 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 test code, 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
pooledStringFieldTypeNameSuffixPolicyCan 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 suffice to use to resolve pooled string type name conflicts with Always or OnConflict suffixing policies."String"
generateProtobufClasses

Specified that protobuf classes should be generated using the protoc code generator in addition to the encoding type specific generated classes. This directive only applies to Xbuf and Xbuf2 encoding types.

Status
colourGreen
titleSince 3.12.5

"String"


Running with Java

To run the generator with java you can use:

...

Code Block
languagexml
<plugins>
  <plugin>
    <groupId>com.neeve</groupId>
	<artifactId>nvx-core-maven-plugin</artifactId>
    <version>${nvx.core.version}</version>
	<executions>
	  <execution>
        <id>Minimal-Messages-Xbuf</id>
        <phase>generate-sources</phase>
        <goals>
        <goal>generate</goal>
        </goals>
        <configuration>
          <modelFile>${basedir}/src/main/java/com/acme/messages/messages.xml</modelFile>
          <encodingType>Xbuf</encodingType>
		  <directives>
			<generateEmbeddedEntityInterfaces>false</generateEmbeddedEntityInterfaces>
		  <directives></directives>
        </configuration>
      </execution>
     </executions>
   </plugin>
</plugins>

...

Code Block
languagexml
titleImport through classpath
<!-- 
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" />

The reason why reason why this works is that the result of running code generation would be:

...