JeeWiz Home  
The Model-Driven System Builder

JeeWiz Architect's Guide
 
Contents  >   6.  Running And Configuring JeeWiz
 


6.3 JeeWiz Property Files

This section describes the general format and operation of JeeWiz properties file. This applies to all the properties files described in subsequent sections of this chapter - build properties, system.properties - and component.properties, described later

Note that this does not apply to the template.properties. This is a much simpler format and so is read using the standard Java Properties class.
The rules are as follows:

  1. JeeWiz property files largely follow standard Java properties file syntax. Each line can be one of the following:
    name [ = value ]
    name [ : value ]
    # comment
    ! comment
    
    In other words, each property line has the property name followed by an optional '=' or ':' and the value - which itself may be null. Comment lines start with '#' or '!'
  2. Substitutions are allowed, being invoked by enclosing a variable name in '${...}'. The variable name must be previously-defined. The only variable name defined by the system is ${jwhome}, which is JeeWiz's home directory. You can also use variables defined earlier in the file or in the ant build job properties: JeeWiz supports this by guaranteeing the order of execution of the property file (unlike standard Java properties).
  3. You should avoid '.'s in property names, either as target or source. If you define a property in 'x.y' format, ${x.y} will later on be interpreted as 'variable x, member y' and so the property you have set will not be accessible.
  4. The ':' separator does not expose the property through the Jwp editor (e.g. in the RSM/RSA plug-in), whereas the '=' does. Therefore the '=' separator is used by default - it gives the modeler the ability to change the property. However, calculated properties, or properties that are obsolete, abstruse or are placeholders for future features, use the ':' separator so they are not visible to modelers. Such properties can of course be changed by architects, by creating a custom meta-model layer with its own system.properties and overriding the property there.
  5. Relative file or directory references (e.g. assemblyDir=specification) are relative to the properties file - whichever one the reference is made in. This means that, if the main buildproperties file for a JeeWiz build references a model.properties file which has in it a relative reference to a file, the reference is relative to the model.properties file because that is where the reference was made.
  6. Properties are a mixture of JeeWiz-defined global names and other names as required by the type of model being compiled.

    The JeeWiz global names (e.g. assemblyDir, templateDir) are described in The Build Properties '.jwp' File section.

  7. '##' Comments (with a leading '##') are used to indicate documentation of the following property, whether commented out or not. All the contiguous lines of '##' comments preceding a property form the block of documentation for that property. This is used in the Eclipse plugin for documenting Jwp files.
  8. If you need to see where a value is being set or any overriding, run the build job in verbose mode, using
    ant -Dpass=-verbose
    
    The 'first file takes precedence' rule follows the philosophy of Ant: higher levels will normally set specific values of interest, but further down the system properties can also be given defaults.

 


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