JeeWiz Architect's Guide - The system.properties File


	The Model-Driven System Builder

JeeWiz Architect's Guide

Contents > 6. Running And Configuring JeeWiz

6.7 The system.properties File

The system.properties file gives a template directory a way of defining top-level properties for the whole build, above the level of the root model object. These are resident in the top-most JeeWiz Ant project (as described on the next page).

The system.properties file is located in the template directory (e.g. jeewiz/resources/base/control) - the one pointed to by the templateDir entry in a build properties file, or by 'parent' in model.properties. If the model.properties has a parent that points to additional template directories, there can be many system.properties files. If so, these will be aggregated as described later.

The system.properties file follows the rules for loading configuration properties, as described in General Rules for Start-of-day Property Files below.

6.7.1	The 'convert()' Feature
6.7.2	Removing Nodes with 'convert'
6.7.3	Removing Unwanted 'convert' overrides

6.7.1 The 'convert()' Feature

The 'convert' feature allows you to change the XML specification as it is read in. There are two reasons for wanting to do this:

It is sometimes important to design/model using logical (target-independent) terms but then operate the build using platform-specific terms. Some features ofo a build can be selected simply by make this change of modelled object name.
In processing complex XML, such as XMI (XML Metatdata Interchange), it is useful to omit redundant layers so that lists are easier to process.

To convert a general modelling term to more specific type at generate time, put a line in a system.properties file of the form

convert(generic-tag)=specific-tag

This says, convert the specification element 'generic-tag' to use the tag 'specific-tag'. For example,

convert(entity)=ejb-entity

which converts the modeled entity into the ejb form of the entity (as opposed to JDO or some other technology). As with all properties in start-of-day files, the first-encountered value is used.

The convert... lines are processed in the same way as other lines: if more than one 'convert' line is present that addresses the same rename, the first one encountered is used. This means that you can override the standard rendering's action by putting a overriding 'convert()' line in the system.properties file for an overriding template directory.

If you want to fix a particular specific type, to stop it being changed by the 'convert()' feature, all you do is use the specific tag in the specification.

The conversion process operates on names only - it takes no account of the parent of the element being converted.

The convert() feature works on all XML specifications, i.e. those read in from a file and those generated by patterns.

6.7.2 Removing Nodes with 'convert'

There are two special values that you can use with 'convert': rather than renaming the named elements, these values cause XML elements to be deleted.

First, the value '-' (e.g. "convert(deleteMe)=-") removes the named element (but retains any nested elements). The net effect is as though the converted element tag had never been input, and all nested elements of the deleted element will be attached to the parent element.

The other special value is '*', and this removes the current element and all its nested elements. In other words, this prunes whole branches from the tree of XML elements.

A good example of the use of the convert facility, including removing nodes, is the system.properties for the XMI Rational Rose XMI importer. This omits a number of nodes using both techniques (as well as using convert() to do renaming). For example, JeeWiz does not use graphical information about model diagrams, hence the line "convert(Diagram)=*".

There is a line "convert(ignore-element)=-" in the system.properties file of the base template directory. This means that '<ignore-element>' elements are ignored - but nested elements within them are not. This is used in a particular situation when aggregating multiple XML files into a composite specification. You are forced by the nature of XML to have a root element in each document, but sometimes this is not necessary. Specifying '<ignore-element>' as the root element and including the base template directory in the build causes that node to be removed, attaching all children in the file to the appropriate parent model object.

The '-' and '*' features are not allowed on the root element of the whole specification - this doesn't make sense.

6.7.3 Removing Unwanted 'convert' overrides

The final special 'convert' is '=', which is the normal operation. The reason this is useful is if you need to override a convert in a rendering meta-model that the current one inherits from. For example, to turn off the action of 'ignore-element' described above, and so allow 'ignore-element' as a name to be processed as normal rather than discarded, use "convert(ignore-element)= =".