JeeWiz Architect's Guide - Model Properties


	The Model-Driven System Builder

JeeWiz Architect's Guide

Contents > 6. Running And Configuring JeeWiz

6.6 Model Properties

The 'model.properties' file, located in the 'template' directory - e.g. jeewiz/resources/j2ee/control - describes the properties of a meta-model, and is used directly by the JeeWiz processor. For compiling meta-models (from a specification into Java objects), this file is required; for simple rendering it is optional.

It does not deal with component object properties (values to be added to component properties). These files are described in the next chapter.

This file has the normal "property=value" format, as described below. The following properties are allowed:

modelName A one-word (no spaces) name for the meta-model. This often ends in 'MetaModel' - e.g. businessObjectMetaModel - if meta-classes are involved, but this is not required. If this template directory holds only a rendering (not a meta-model), the 'Model suffix is not used - e.g. weblogic6, jboss3.

This name is intended to document the model.properties to other meta-programmers. It is not used elsewhere.
description A description, of 1-4 words, for the model. A model should define this if it wants to feature in the list of models that the user can select from the drop-down list in the editor's new project dialog. Normal usage is that the standard JeeWiz directory (under resources/*/control) should specify the description and custom derivations should not change it. In other words, if you are defining a local customisation, don't set this property. If you are defining a general-purpose model or rendering, you must set this.
package The package, or list of packages, in which top-level objects are to be found.

A single package is more usual here. If a list is used, the components should be separated by ';', ':' or ','.

The root element in the assembly.xml file for a specification must be mapped to a Java class. This is done by transforming the root element's name from XML standards to Java class standards - e.g. 'ejb-jar' gets converted to the Java class name 'EjbJar' - and this class is looked up in the available packages. All component packages in all model.properties files are concatenated to create the classpath, with the component packages from the first model.properties in the chain coming before - and so taking precedence over - packages encountered in later model.properties

This feature allows the user to override standard JeeWiz classes with company variants and locate them in the company's package structure. For example, to add extra features to an application, you could create a class com.mycorp.jwoverrides.Application, and then find this as a top-level object by specifying:

package=com.mycorp.jwoverrides;uk.co.nte.jw.components.j2ee

in the model.properties file.
The 'package' specification only applies to the top-level object (i.e. the root element in the assembly.xml file for the assembly directory). The types of lower objects (i.e. nested elements) are defined by methods on the nesting elements.

topComponents The top components allowed in this model. This is normally a container-like buildable unit: a jar file in the object model; an application or ejb-jar in the J2EE model; a 'table of contents' in the documentation model. The entry for the J2EE model is:
topComponents=application

abstract This field is for documentation only; it is not used by the JeeWiz engine. Set this 'true' ("abstract=true") if the model should not be used directly by users. The J2EE model is an example of this: to build deployable applications, we need to know the particular application server to build for, so the J2EE model itself is marked as abstract.
parent This entry is optional and defines one or more 'parent' template directories. If multiple parent directories are specified, they should be separated by either the path separator character (':' on UNIX, ';' on Windows) or the ',' - the ',' works on both platforms.

A parent directory specified in either way must exist; if not, the build stops.

The 'parent' of a model adds additional (a) meta-classes and (b) Velocity scripts to the current model. This is recursive - the parent property can point to a directory that itself has a model.properties file with a 'parent' entry. Therefore a top-level model can have many layers of parents.

For example, an example inheritance chain of the J2EE deployment models might be

WebLogic, Websphere, JBoss... -> J2EE -> Screen -> Business Object -> Language (Java) -> Base

If the 'parent' property is missing, this is the 'end of the line' for searching for Velocity macros and other attributes of the model. If the parent directory is specified, this must be the directory in which there is another 'model.properties' file, defining further aspects of the model. If the parent directory refers to a directory that has already been encountered in building the chain, it is ignored. When there are multiple template directories specified in the 'parent' property, these are processed left-to-right, with all the parents of the first template directory appearing in the final list before the parents of subsequent template directories.
The parent directory is specified relative to the directory in which the model.properties is located (so '.' would actually refer to the be the same directory and be ignored).
Note that, whereas other property files allow substitution of variables (in ${...} format) from elsewhere in the object model, the parent entry only allows substitution of system properties. There are two important variables that are very useful at this point:

${jwhome} The JeeWiz home directory - this is set by the JeeWiz build jobs, and is what you would use to reference standard JeeWiz models.

${assemblyDir} The assembly directory (has top-level assembly.xml for current build). If the assemblyFile property was used to define the specification, the assemblyDir becomes the directory holding that file.

If you need to pass in your own property settings into JeeWiz, see the Running JeeWiz for instructions.
componentJar This is intended for advanced use of the models, and allows you to split the rendering of a model from the model's component objects (i.e. from the components.jar). You can then have a specialised rendering inheritance chain with no jar files defining meta-classes: they all come from the componentJar references. The value specified here should be the name of a jar file in another model, normally 'components.jar'. If the file is relative, it is relative to the directory containing the model.properties file.