core package

The ModelAnt CORE package contains tasks, types and macros to provide model-independent or reflective access to models and model elements, like:

compare.metamodels macro

This task adapts the general compare.models task by providing comparison rules for models in MOF 1.4. The MOF models are used mostly as meta-models, this way defining other modeling languages, so this macro helps identifying what transformations are needed when converting a model from one meta-model to another, i.e. expressing the same model from one modeling language into another. For example: In order to identify the transformations needed to convert an UML 1.3 model to UMl 1.4, the following procedure was applied:

1. start with compare.metamodels with no nested elements, set up to compare both meta-models.
2. do a meta-model comparison
3. use the reported differences to identify the corresponding meta-model elements and define them as nested <equals>, <except> or <map> elements in the compare.metamodels macro
4. repeat steps 2 and 3 until no more differences are reported
5. the defined <equals>, <except> or <map> elements define the transformations to be used in copy.in.metamodels task

compare.models task

Uses the MOF Reflective API to compare models, so the comparison is independent of their meta-model. In order to find the corresponding model elements this task uses a list of nested <equals> elements that define for each meta-class of that model which attributes and associations must have equal values in order to treat two of its instances as equal.The <equals> defined for a meta-class is valid for all its subclasses. Any <equals> defined for a subclass inherit the <equals> set for the super-classes.

NOTE: The default comparison specifies no attributes and associations. As a result, if no comparison is defined, all model elements are treated as comparable.

In order to state manually any correspondence between model elements, identified by other means, provide corresponding <map> elements. For example, if a-priori a correspondence between model elements is known, state it as nested <map> elements.

The results of the models comparison are sent to the tasks in comparison element with some specific conventions. See the ant.doc documentation for more details.

copy.in.metamodels task

Copies a model from one meta-model into another meta-model, i.e. it represents a model from one modeling language to another modeling language. The correspondence between both meta-models (languages) is stated in nested <map> that could have been identified in compare.metamodels task.

print tasks family

These tasks print a model element considering it in different meta-models and for different purposes. See the ant.doc for more details.

ref. tasks family

They access the attributes and associations of the object in a model using the MOF Reflective API

wrap tasks family

wrap
Uses a registered factory and builds a wrapper around the model element or a collection of such. This task wraps an object into a corresponding wrapper object using a corresponding factory which has been registered previously. The object is provided as a value of the property named in “property” attribute (default: this) and is stored in the property named in “name” attribute (default: this)

wrap.factory.register

Registers a factory of model element wrappers, adding more features to the model. This class is a task that registers a new factory of wrappers for the subclasses of the class/interface provided. The factory is loaded through the classpath[ref] provided, whereas the root class/interface is searched through the system class loader.

wrap.factory.unregister

Unregisters a factory of model element wrappers. This class is a task that unregisters a factory of wrappers. The factory class is loaded/searched through the classpath[ref] provided.

wrap.method

Wraps a model element, invokes a method on the wrapper and stores its result in a property. This task calls the method with the name provided and arguments, on the wrapper object for the referred model element and stores the result into the property with the name provided. Void methods are treated as producing null result. It allows adding nested tasks, running in a separate environment, so they could prepare the interim data and prepare the “property” value without affecting the task’s environment.

See also the core package documentation.