Metadata

Describes various attributes of a model, including its name, dependencies, and version

Description

A Model contains all of the Model Description Language elements that make up a service. The metadata specifies the name, namespace, module name, version, checksum, and dependencies for the model.

A model may also be known as a repository in documentation.

By default, a published model is named: nexj-meta-<PROJECT_NAME>-<REVISION>-<VERSION>-<CHECKSUM>.jar

Properties

baseChecksum : hex

Each model may specify a base model whose contents become a starting point for additional development.

Elements in the base model can be modified and expanded through customization. If a model is "based" on another model, it will inherit all of the base model's metadata. Models reference their base model by namespace, version, and checksum

Valid values based on“string”.
[0-9A-fa-f]*

baseNamespace : anyURI

Each model may specify a base model whose contents become a starting point for additional development.

Elements in the base model can be modified and expanded through customization. If a model is "based" on another model, it will inherit all of the base model's metadata. Models reference their base model by namespace, version, and checksum

baseVersion : string

Each model may specify a base model whose contents become a starting point for additional development.

Elements in the base model can be modified and expanded through customization. If a model is "based" on another model, it will inherit all of the base model's metadata. Models reference their base model by namespace, version, and checksum

compatibleChecksum : hex

A compatible model is used to ensure API compatibility

If a compatible model is specified, and API elements in the model that are specified as `compatible` cannot be modified. See the API elements for information on this feature. Models referect their compatible model by namespace, version, and checksum.

Valid values based on“string”.
[0-9A-fa-f]*

compatibleNamespace : anyURI

A compatible model is used to ensure API compatibility

If a compatible model is specified, and API elements in the model that are specified as `compatible` cannot be modified. See the API elements for information on this feature. Models referect their compatible model by namespace, version, and checksum.

compatibleVersion : string

A compatible model is used to ensure API compatibility

If a compatible model is specified, and API elements in the model that are specified as `compatible` cannot be modified. See the API elements for information on this feature. Models referect their compatible model by namespace, version, and checksum.

coreVersion

The core version specifies the minimum core version of the platform code that this model requires.

The core version of the platform code (the Java code and .xsd structure for the Model Description Language) is specified in a Version.java file. This is used to ensure compatibility of the platform structure and behavior with your model. Each version of NexJ Studio has a core version which can be seen in the help/about dialog.

It is common for the core version of a model to be specified with a plus sign afterwards. This indicates the model is compatible with the specified core version and above.

Example: <Metadata name="NexJ Widget" coreVersion="3.0+"/>

Valid values based on“string”.
[\p{N}]+(\.[\p{N}]+)*\+?

description : string

A short description of the purpose and usage of the service

A longer description of the purpose, dependencies, setup, and opteration of the service should be documented in a readme.md file in the project folder.

language : languageType

Scripting language. Specifies language in which expressions are scripted by default.

When blank in particular script elements, the scripting language specified in the .metadata file is used. If also unspecified in .metadata, the language defaults to scheme.

Valid values based on“string”.
scheme	scheme scripting language
js	JavaScript scripting language

module : identifier

The module name will be applied to the beginning of any elements in this model automatically.

This property is used for namespacing all elements in a model. For more targeted namespacing, you may also use folders.

Example: If the module is "eas" then a message called meta/messages/T1.message will have a full name
of "eas:TI".
If the message was called meta/messages/feature1/T1.message the full name would be
"eas:feature1:T1".
If there were no module set and the message was called meta/messages/feature1/T1.message
the full name would be "feature1:T1"

Valid values based on“string”.
:?[\p{L}_][\p{L}\p{N}_](:[\p{L}_][\p{L}\p{N}_])*	Value must begin with a letter or an underscore. Case and length are not restricted. Letters, numbers and underscores are allowed. Colon is used as a scope separator. Spaces and other punctuation characters are not allowed.

name : string

The display name of the model

The name of the model comes from the .project file. The .metadata file's name property declares the display name.

Example: In the finance project, the .project name property is "finance" and the .metadata file's
name property (the display name) is "NexJ Finance".

namespace : anyURI

A globally unique URI that identifies the model. Used for metadata, persistence storage and RPC request matching.

Because of uniqueness requirement, using a registered domain name is recommended.

Example: An eas model created for Appco Systems Inc. might use the value: appco:com:eas

override : boolean

Specify that this model's resources cannot be overridden

This means this model's resources cannot be overridden when mixed into another model, even if the mixin "override" property is set to true.

revision : string

Identifies the release that is offered externally to customers

By convention, the revision number identifies the release that is offered externally to customers (i.e delivered software). Technically, the revision string has no significant meaning; nothing within the application depends on the revision number. We will keep revision numbers consistent across the repository stack where possible. The revision number will be modified as a release plan is finalized.

The revision number format is typically: <MAJOR>.<MINOR>.<PATCH>.<HOTFIX> (<DESCRIPTION>) where:

<MAJOR>  - the major revision number, often considered the version of the framework
<MINOR>  - the minor revision number, often considered the version of the application on the
                     current framework; resets to one (1) whenever major changes
<PATCH>  - the patch number for this major.minor; resets to zero (0) whenever major.minor change
<HOTFIX> - the hotfix number for this major.minor.patch; resets to zero (0) whenever
                     major.minor.patch change
<DESCRIPTION> - a description of the revision, such as (GA), (RC1 Hotfix 3), etc.

Example: Example revision numbers
   2.4.0.0
   2.4.1.0 (RC1)
   2.4.2.1 (RC2 Hotfix 1)

upgradeChecksum : hex

An upgrade model is the new version of the base or mixin model, until the upgrade is complete.

When the upgrade is complete, the upgrade model becomes the new base or mixin model and the original base or mixin is no longer in use. Models reference their upgrade model by namespace, version, and checksum

Valid values based on“string”.
[0-9A-fa-f]*

upgradeNamespace : anyURI

An upgrade model is the new version of the base or mixin model, until the upgrade is complete.

When the upgrade is complete, the upgrade model becomes the new base or mixin model and the original base or mixin is no longer in use. Models reference their upgrade model by namespace, version, and checksum

upgradeVersion : string

An upgrade model is the new version of the base or mixin model, until the upgrade is complete.

When the upgrade is complete, the upgrade model becomes the new base or mixin model and the original base or mixin is no longer in use. Models reference their upgrade model by namespace, version, and checksum

version : string

The version number denotes the version of the database schema

Technically, the version number is a free-form string denoting the version of the database schema. The version number is "bumped" whenever there is a new label in the Main.upgrade file. This typically happens whenever there is a change to the database schema, but one may decide to bump the version if there is a significant API change that would affect clients.

For the Core model, the version number is <NUMBER> which is incremented with each change to the database schema or, on rare occasion, when a significant API change occurs. (Note that Core's version number was originally oc<NUMBER> for open core.)

For all other models, the version number is <NUMBER>.<BASE_VERSION> where <NUMBER> is incremented with each change to the database schema or, on rare occasion, when a significant API change occurs. And <BASE_VERSION> is the version number of the base repository, a number that will only change for the current repository when a merge of a newer base is done.

Example: Example version numbers:
   For core, 18
   For enterprise, 15.18
   For crm, 312.15.18
   For finance, 170.312.15.18

Content

Sequence of:
- t_Metadata_Mixins [0..1] - A list of other models to import and load (mix in) along with this model's resources
- t_Metadata_Imports [0..1] - Advanced: do not use this property
- t_Metadata_Resources [0..1] - Resources may be conditionally included or excluded from metadata loading based on command line or environment properties.
- any [1..1]

Example

nexj-meta-finance-9.1.0.0-1081.1307.167.53-c96c9af7.jar

t_Metadata_Mixins
A list of other models to import and load (mix in) along with this model's resources
t_Metadata_Imports
Advanced: do not use this property
t_Metadata_Resources
Resources may be conditionally included or excluded from metadata loading based on command line or environment properties.

Parent topic: references