6.2 'Start-of-day' Configuration

The remainder of this chapter describes the 'start of day' sequence of the engine and how it loads its configuration.

6.2.1  Configuration Structure

1. Your Ant build calls into jwrun or jwcall, as described in the previous section. jwrun/jwcall will set up defaults for various properties, such as jwTarget and overallBaseDir.
2. This eventually links into the JeeWiz main task - uk.co.nte.jw.engineTasks.JeeWizTask. When JeeWiz is started using jwcall, the JeeWiz task has a link out to jwcall to pick up values set there, as long as the inheritAll flag is not set false. This means that the properties from the calling Ant build script are available.

   It then sets all incoming "true" and "false" values to boolean true and false, so that these can be correctly referenced as booleans. (In Velocity if $x=="false", #if( $x ) will succeed - which probably is not what was intended.)

   The task then sets booleanTrue, booleanFalse, jwhome (which is required), basedir (copying the Ant value), and pathSeparator/fileSeparator from the Java System path.separator and file.separator values.
           

3. Next, the JeeWiz task loads up all the configuration properties that might have instructions for the engine. The configuration properties are aggregated from files defined by the following properties, with earlier files being the more precedent. All these files are optional:
   • The file named in the property "buildproperties", if any.
         Per-run properties, e.g. to change generated log level in Java code.
   • The file named in the property "userbuildproperties", if any.
         Seemed like a good idea at the time
   • The file userhome/.JeeWiz/build.properties, if any, where userhome is taken from Java system property "user.home".
         This holds per-user defaults (e.g. personal location for application servers).
   • jeewiz/bin/build.properties (Sopera/Eclipse Swordfish only)
         This holds per-installation defaults for JeeWiz V4.
   • The file named in the property "extrabuildproperties", if any.
         This should hold per-installation defaults (e.g. project standard location for application servers).
   This concludes the reading of the properties that can affect the configuration of the build. In other words, all the properties recognised by the engine must have been set at this point.

   It is also possible to define configuration parameters in this phase that will be acted on by the generation system templates and patterns rather than the engine. The values read from these configuration files and read into a top level properties map, which is available as a last resort (i.e. least precedent lookup) for values used by generation systems. For example, the jeewiz/bin/build.properties has the sort of configuration that is allowed. This is very definitely about configuring the generation system, not the engine.

4. If there are any additional specifications - additional to the main XML document, that is - these are read in now. These are specified by addSpec* variables For example, this is used to build the meta-models: parent meta-models are accessing using the additional specifications. When an additional specification is read in, its root model object (which is the Java representation of the root XML element) is set into the value of a top-level property.
5. The 'templateDir' property is now used to determine the stack of template directories. This defines where the renderings (templates, patterns, meta-class configuration etc.) for the build will come from.
6. The file or files for the model - the 'main specification' - are determined by the assemblyDir or assemblyFile properties, as described in the section on build properties files.

6.2.2  Substitution Values in Configuration Files

1. basedir - this is from Ant
2. jwhome - the object for the home directory. You can reference properties using the '.' notation.
3. fileSeparator - '\' on Windows, '/' on UNIX
4. pathSeparator - ';' on Windows, ':' on UNIX
5. booleanTrue - this is placed into the context as a java.lang.Boolean("true") object and so can be used for Velocity true/false values
6. booleanFalse -java.lang.Boolean("false")

6.2.3  Using Configuration Files

In configuring a JeeWiz build for team use, each properties file has its purpose. These properties will set defaults that are provided for in generation systems, typically via the systems.properties file:

1. Use the properties file pointed to by the buildproperties property as the main file defining a build for a particular application. This should be provided by a team meta-programmer and be standard for the team and a given build. Because it is loaded up first, it fixes the values for the properties that it defines (definitions for the same property in later files will not be acted on).
2. Use the properties file pointed to by the userbuildproperties property as the file for changes or variations for the current build. This can be set by individual users to alter the build.
3. Use the userhome properties file for personal configuration. For example, this is a good place to hold information for own database, as some databases are hard to reconfigure.
4. Use the properties file pointed to by the extrabuildproperties property to point to a standard set of defaults provided by the generation system. This is the role of the jeewiz/bin/build.properties in JeeWiz version 4: it provides an example set of defaults for JeeWiz V4 J2EE systems, that will need adjusting for your environment. If you wanted to build a V4 J2EE system, you would point extrabuildproperties at jeewiz/bin/build.properties. (In V4, this value was hardcoded into the engine.)

   Because this is the lowest precedence properties file, the values given here can be overridden in any of the other files.

Copyright (c) 2001-2008 New Technology/enterprise Ltd.