JeeWiz Architect's Guide - Transforming Models To Systems


	The Model-Driven System Builder

JeeWiz Architect's Guide

Contents > 2. Overview

2.5 Transforming Models To Systems

Previous pages in this chapter have talked about the syntax of the JeeWiz input, and how we use meta-models to define the expected structure of the input.

Now we start on the first concept in a series about how we render the input into complete systems. We call the process of converting an input into the generated system 'rendering'; the word 'transformation' is also used.

2.5.1	Assembly By Ant
2.5.2	The Context for Ant Substitutions
2.5.3	Pipelining

2.5.1 Assembly By Ant

The generated system is produced by running Ant in a tree-walk. This walks the model, and at every model-object runs an Ant job, if the meta-class has a build.xml available for it. The order is bottom-up, left-to-right. The following diagram shows our previous example, amended to show the build order.

We should stress that there doesn't need to be a build.xml for every level - only if there some output needs to be generated.

What can you do in the build.xml? Naturally, anything you can do in a normal Ant build. This means that all the specialised processing tasks of Ant are available to you. In addition, JeeWiz provides custom tasks for

running Velocity to create new files from templates
running Ant in a JeeWiz-specific way.

The tree-walk implemented by JeeWiz is the mechanical part of making automatic assembly of large systems possible. We will discuss further aspects of this later.

2.5.2 The Context for Ant Substitutions

Ant has a substitution mechanism that allows a string-value property to be substituted. JeeWiz has enhanced Ant so that, after the initial search in Ant's properties, the subsititution mechanism also searches for values using the current model object as its context. For example, say we are building the entity in the above example, where 'name="Account". If the text

${name}

is used in the Ant build job and there is no 'name' property defined in Ant in this build.xml, then JeeWiz will retrieve the value from the model object - and substitute 'Account'.

This means that the Ant build job can be directly model-driven; there is no need to have a separate Ant configuration. For example, here is a velocity task

<jwVelocity    template="entityBean.vm" 
               file="${outputFilePath}/${name}.java"/>

The properties 'outputFilePath' and 'name' would come from the model; directly reflecting the contents of the model.

We will shortly generalise this feature : it is possible to get values from parents of the current model object, or from the overall build configuration.

This feature is important because JeeWiz supports reuse of meta-models and related renderings. If the meta-programmer had to configure all the properties required by all the lower layer build scripts in the model object tree, it would be extremely difficult and error-prone. The situation is exacerbated by the number of properties a single model object can end up with: 40 or 50 is not unusual. We therefore provide an automatic solution that does away with explicit configuration (a common theme in JeeWiz).

2.5.3 Pipelining

One of the artifacts that the templating facility of JeeWiz can create is more Ant build scripts. Using Velocity, we can substitute in variable names, path names, configuration items and so on to create a build script that is adapted to the requirements of the meta-class.

A common pattern for using this feature as part of a large-scale build is shown by the J2EE ejb-jar (EJB Jar) and application.

In terms of the model object tree, the 'application' model object is parent of the 'ejb-jar'.

1	Remembering the bottom-up tree-walk for running Ant on the model objects, the Ant build for the ejb-jar model object is done first. One task of this is to render the Velocity script "buildScript.vm" into the build.xml file for building the real system. (If there are many ejb-jars in the model, they will be built here in left-to-right order.
2	Then the Ant build for the application model object is started.
2a	Like the ejb-jar, the application MO's build.xml creates the build.xml to generate the real application.
2b	Once all the generation steps have complete, the application MO's build.xml calls into the generated build.xml - it generates the application there and then.
2c	Part of application's generated build script contains calls to build each of the ejb-jars, using each ejb-jar's generated build.xml.

The pipelining comes in step 2b, where the application model object builds itself.

Also note that this approach is recursive and easily modifiable. For example, the application depends on the ejb-jar's build.xml, but not its exact details. This means that the ejb-jar build can be modified independently of the application's build.