JeeWiz Architect's Guide - The Ant Build files


	The Model-Driven System Builder

JeeWiz Architect's Guide

Contents > 7. Finding Values and Files

7.6 The Ant Build files

Each meta-class can have two Ant build scripts associated with it, as described in the following sections.

These Ant scripts can also use special JeeWiz tasks, as described in the last section.

7.6.1	build.xml
7.6.2	uptodate.xml
7.6.3	Ant Tasks

7.6.1 build.xml

The per-meta-class 'build.xml' file describes how to build this component. It is optional.

The build.xml file can invoke any Ant task - compiles, copies etc. The particular JeeWiz task of interest is the Velocity task, which takes a script and converts it into code.

If present, the build.xml file is located in the directory /. The build.xml file is searched in all the 'models', as specified in the model.properties '.parent' chain. For example, when building the standard j2ee/helloJWorld example, the list of file paths checked to see if there is a build.xml for the business-method object are:

jeewiz/resources/jboss3/control/business-method/build.xml
jeewiz/resources/j2ee/control/business-method/build.xml
jeewiz/resources/bizobject/control/business-method/build.xml
jeewiz/resources/java/control/business-method/build.xml

The first file found from the list is used. This means if you implement your own overriding models, you can override build.xml. If you do this, you have to replace the complete file.

You can define two targets in the current J2EE system - 'build' and 'clean'. If you build your own model using the model-building capabilities, you can use other targets: there is nothing built into the JeeWiz engine restricting the target names.

The target used is defined by the 'jwTarget' property passed into the JeeWiz Ant build. jwTarget is described in Interface To jwrun.xml.

7.6.2 uptodate.xml

The uptodate.xml file is used to determine if the current component is up-to-date. If so, it stops the build.xml file being executed for the current model and for all children.

The uptodate.xml file is searched for in the same way as for the build.xml described in the previous section.

The J2EE system uses up-to-date checking at the application, EJB jar and EJB levels:

application/uptodate.xml
ejb-jar/uptodate.xml
session/uptodate.xml
entity/uptodate.xml
message-driven/uptodate.xml

Note that when uptodate.xml says a component is up-to-date, that implies all its children are up-to-date as well: this stops all children being built. While this can cut generate time dramatically, you must also be sure to take into account possible changes affecting children of the current model object as well as changes to the object itself.

The uptodate.xml script is invoked directly from the JeeWiz engine. To tell the engine that this component is up-to-date, set the property 'jw.export.property' to the name of a property you want export back to the calling ant build job:

<property name="jw.export.property" value="uptodate"/>

If the 'uptodate' property is set in the called Ant build, its value is copied back to the caller; if the property is not set, the property is made unset in the caller by removing it if necessary. The uptodate processing in the engine looks for the 'uptodate' property after 'uptodate.xml' has run; if it exists, the object is considered up-to-date and all further processing of the object and its children is terminated.

7.6.3 Ant Tasks

There are two Ant tasks provided by JeeWiz, referenced in bin/jwbuild.xml, which are only for JeeWiz use: these are <jeewiz> and <jwAntInternal>.

There is another special JeeWiz task, <jwVelocity> for running Velocity scripts. This is described in the next section.

The other JeeWiz-specific task, <jwAnt>, is provided for use in JeeWiz build scripts. It is based on idea of the standard '<ant>' task, but with the following differences:

The 'antFile' property, if a relative file, will be searched for using the model template directory chain; if the file is absoluete, it will be looked up as specified. You can always make a reference absolute by starting it with '${ant.file}/..' which gives the absolute path to the current directory.
jwAnt supports searching for substitution in model objects, as described above.
There is a 'required' property. By default this is true; you can make an included file optional via 'required="false"'. This is used to invoke optional call-outs to 'concrete' models (like weblogic6 and jboss3): by setting the 'required' on the invoked build to false, you make this feature optional. See ejb-jar's build.xml for an example and the section on Using Overriding Files above for further explanation.
<jwAnt> supports the 'ant.file' of 'super'. This supports rendering inheritance of build files. If there is a 'parent' build file (in the sense of rendering inheritance) then it will be invoked. If there is no such build file, then the action depends on the setting of the 'required' property. If the required flag has been set to true (or defaulted), then the action if there is no such build file is that a build error occurs; this allows you to specify that this build file depends on the inherited build file. If the required flag has been set to false, then no action is taken: the <jwAnt> call then becomes a no-operation. By using &jwAnt; with a required
To support 'uptodate' processing, the antTask handles the 'jw.export.property' property specially, as described in the previous section.
There is a 'quiet' flag, which is false by default. To have quiet invocation of these scripts, use 'quite="true".
jwAnt doesn't support the 'dir', 'output' and 'inheritAll' features of the standard <ant> task. The base directory of the called task is the same as the current base directory - which is the directory holding the build file.