Trengen: Trentino validation and code generation tool

Overview

Trengen is the validation and generation tool of Trentino runtime. It validates users contribution and generates many artifacts necessary extra artifacts that are used by the runtime to access, execute and manage the deployed contribution. Generated artifacts include:

  • Reflection code: C++ source code necessary by the runtime in other to perform dependency injection.
  • Serialization and Deserialization code: needed by the runtime or by a Trentino client to handle remote procedural calls.
  • Proxies and skeletons classes for the defined services

Contribution validation

Usage

Trengen validates the contribution against Service Component Architecture v1.1 (SCAAM v1.1) and SCA client and implementation Model for C++ Specification V1.1.



usage: Trengen usage
 -cf,--config_file <file>
 Read options from a configuration file
 -cont <contribution_directory>|<zip_file_of_contribution_directory_tree>
 specifies the root directory of SCA contribution, can be a zip file or a
 path
 -D <property=value>
 use value for given property. Only used together with 'cf' option
 -d
 Trengen runs in debug mode
 -disable_exit
 disable exiting when Trengen is finished. USED for Development purpose
 only
 -ec <directory list>
 Comma or semi colomn separated list of paths to contributions that are
 imported by this contribution. Use this when this contribution import
 another one using the <import.cpp> tag in sca-contribution.xml
 -exclude <directory pattern>
 comma or semicolon separated list of directory to be excluded. e.g
 '*/boost/*
 -gencppitf <a directory, a path to .java or .tidl.properties file>
 generate C++ interface from a given interface definition file.
 The java file based model or a tidl configuration file containing the
 path of the java based model. If the path is a directory, then all
 *.tidl.properties files in the given directory will be processed.
 -generateCMake <true|false>
 Generate CMake file, default to true
 -h,--help
 print this message
 -inc <header file name>
 name of an optional header file to be included in the generated c++
 header file.
 -includedirs <directory*>
 comma or semicolon separated list of directories, service and component
 header files are located. Default are <root>, <root>/services
 -install_dir <contribution_installation_directory*>
 Optional. Trengen generates a Cmake file for the generated code. It
 requires the location where binaries will be installed as result of a
 Cmake install. Default value is the 'META-INF' of the
 <contribution_directory>
 -lib <library names>
 Library names (not path) of the service/component implementations. Names
 are separated by ';' or ','. Default is the contribution name.
 -libdirs <directory*>
 comma or semicolon separated list of directories, where libraries
 containing the service/component implementations are located. Default is
 <contribution> and <contribution>/lib.
 -no_inline <true|false>
 default false: true if the generated code should not be inline. In that
 case a cpp file is generated (only) for complex types
 -outdir <output_directory>
 If provided it specifies the output directory for the Trengen generated
 code. Default is <input_directory>Gen.
 -rootdir <root directory>
 alternative root directory used for searching header files and component
 types. Does not apply to composites.
 -rtdir <<runtime_directory*>>
 specifies the location of the Trentino Runtime. Optional since Trengen
 tries to resolve the runtime path automatically.
 -v
 If provided, Trengen shows info logs.
 
		Trengen outputs the generated code along with a cmake file under the [ContributionName]Gen folder at the same level with the contribution folder. The user should compile the generated code according to the provided CMake. As the result of the compilation of generated code the “sca-contribution.dll”, “sca-contribution.lib”, “sca-contribution.conf “ files are placed under the META-INF folder of the contribution. (For detailed sequence please see section :Compiling and Installing A Sample Contribution)


 

The validation includes a syntax and a semantic validation.

Syntax validation

The Syntax validation validates the contribution and its artifacts (componentType files, composites, contribution documents, ...) against specified xsd schemas provided by the SCA specification.

  • *.componentType files are validated against sca-interface-cpp-1.1-cd06.xsd
  • *.composite files are validated against sca-implementation-cpp-1.1-cd06.xsd, sca-implementation-composite-1.1-cd06.xsd, sca-interface-cpp-1.1-cd06.xsd, sca-interface-wsdl-1.1-cd06.xsd and sca-binding-sca-1.1-cd06.xsd.
  • sca-contribution.xml is validated against sca-contribution-cpp-1.1-cd06.xsd.
  • sca-definitions.xml is validated against sca-definitions-1.1-cd06.xsd.
To get the list of all syntax constraints that are validated by Trengen, please see Appendix A.

Semantic validation

Semantic validation takes place after and if syntax validation was successful. It includes validation of the relationship between artifacts, the consistency of the whole contribution as defined by the SCA Specification

Assumptions and limitations

  • Trengen have to parse you provided source code to check that required dependency injection points (setter accessors) are implemented. Trentino only parses header files and no *.cpp files. It therefore assumes that at least the definition of your setters are in the header files to be parsed.
  • TrenGen validates/parses/uses only 1 contribution (given as a zip file or a directory).
  • TrenGen does not support domain-specific issues (like import, export, domain-level composite).
  • TrenGen does not support nor validate sca policies and intents, since they are currently not supported by Trentino.
  • We assume that the composite files will be unique within the whole tree of the given sca validation directory (param of trengen)
  • While finding the matching .componenttype file of a component, if the component/implementation/@componentType is not defined, we search the .componenttype file named according to the component/implementation/@class within the whole contribution tree.
  • We have assumed the specification regarding the service interfaces(i.e ASM60005) are also valid for the callback interfaces.
  • Namespaces defined by extra xsds and annotations are not supported for now. For extensive property support it might be required.