MinuteProject needs a main configuration file to operate. This page describes how to configure it.
The configuration aspects are divided in three parts:
  • Global configuration matching all templates and/or model
  • Configuration concepts dealing with the data model and its enrichment.
  • Configuration concerns dealing with the choice of the target technology(ies) against which the generation is performed.

Configuration


The configuration file is an xml file.
The following description will reference the configuration of the different nodes starting from the root one.
From release 0.5 on, the directory mywork/config holds a configuration file mp-config-sample.xml that contains the different node configuration sample.


Global configuration

Target global configuration

Enable updatable code

Use to generate the generated artifact comment snippet to enable updatable code feature. How-to use updatable code is describe here.
<generator-config>
  <configuration>
   <conventions>
       <target-convention type="enable-updatable-code-feature" />
    </conventions>

Remove Timestamp

The generated artifact include in comment the licence, some artifact minuteproject metadata attributes as well as the timestamp when the code was generated.
Over consecutive generations, the generated artifacts may only changed on their timestamp. It may be interesting to remove the timestamp in some case.
<generator-config>
  <configuration>
   <conventions>
       <target-convention type="disable-timestamp-comment-marker" />
    </conventions>


Model configuration

The Model is composed of the data model, business model nodes.

Data Model Configuration

Model identity

Gives your model identity parameters.
In the node generator-config.configuration.model fill the following attributes
  • name
  • version (used for maven)
  • root package
Example
<model name="petshop" version="1.0" package-root="sf.net.mp.demo">

Model reference

Gives the location of your model using data source parameters
In generator-config.configuration.model.data-model.dataSource fill the following attributes
  • driverClassName
  • url
  • username
  • password
Example
<dataSource>
   <driverClassName>org.hsqldb.jdbcDriver</driverClassName>
   <url>jdbc:hsqldb:hsql://127.0.0.1:9001/petshop</url>
   <username>sa</username>
   <password></password>
</dataSource>

For DB2 and Oracle Database please specify the schema (usually the same as the username)
In generator-config.configuration.model.data-model.schema add
  • schema value
Example
<schema>schemaName</schema>

PrimaryKey Policy

Gives the primary key policy for your model, the current primary key supported are sequence and autoincrement.

Sequence primary key
For Sequence Primary key, two types are supported. One global sequence for the entire model, or one per table. In this case the name of the sequence is deduced the following way (prefix+table-name+suffix).

In generator-config.configuration.model.data-model.primaryKeyPolicy fill the following attributes:
  • oneGlobal or oneForEachTable
In generator-config.configuration.model.data-model.primaryKeyPolicy.primaryKeyPolicyPattern fill the following attributes:
  • prefix
  • suffix
  • name="sequencePattern"
Example
<primaryKeyPolicy oneGlobal="false" oneForEachTable="true">
  <primaryKeyPolicyPattern prefix="" suffix="_SEQ" name="sequencePattern">
  </primaryKeyPolicyPattern>
</primaryKeyPolicy>
Autoincrement primary key

In generator-config.configuration.model.data-model.primaryKeyPolicy fill the following attributes:
  • oneForEachTable="true"
In generator-config.configuration.model.data-model.primaryKeyPolicy.primaryKeyPolicyPattern fill the following attributes:
  • name="autoincrementPattern"
Example
<primaryKeyPolicy oneForEachTable="true">
  <primaryKeyPolicyPattern prefix="" suffix="" name="autoincrementPattern"></primaryKeyPolicyPattern>
</primaryKeyPolicy>

Business Model Configuration

This configuration defines the scoping and packaging (grouping entities in sets) of your data model.

Scope

This gives the ability to select with entity are to be include or exclude from the generation.
In generator-config.configuration.model.business-model.generation-condition fill the following attributes:
  • default-type with 'exclude' or 'include'. If not specified, the default value is 'include'
In generator-config.configuration.model.business-model.generation-condition.condition fill the following attributes:
  • type with 'exclude' or 'include'. Normally it is the opposite of the default-type.
  • startsWith
Example
This snippet shows how to generate for all the entities except those whose name starts with 'SYS_ADMIN_'
<generation-condition >
  <condition type="exclude" startsWith="SYS_ADMIN_"></condition>
</generation-condition>
This snippet shows how to generate only for the entities whose name starts with 'SYS_ADMIN_'
<generation-condition default-type="exclude">
  <condition type="include" startsWith="SYS_ADMIN_"></condition>
</generation-condition>

Business Package

This gives the ability to group entity in logical business package set.
In generator-config.configuration.model.business-model.business-package fill the following attributes:
  • default
In generator-config.configuration.model.business-model.business-package fill the following attributes:
  • type with 'package'
  • startsWith
Example
<business-package default="mybusiness">
    <condition type="package" startsWith="ADMIN_" result="administration"></condition>
    <condition type="package" startsWith="FIN_" result="finance"></condition>
</business-package>

Business Model Configuration conventions

There is a set of conventions that can be used to act globally on your model.
Conventions are applied after individual entity and field enrichment.
Conventions are applied in the order they are inserted, so the order is extremely important. Same set of conventions in different order might lead to different results.

Entity naming convention

Apply-strip-entity-naming-convention convention will remove entity whose name start or end with a certain pattern.
In the following snippet
<enrichment>
...
 <conventions>
  <entity-naming-convention type="apply-strip-table-name-prefix" pattern-to-strip="SYS,FIN"/>
  <entity-naming-convention type="apply-strip-table-name-suffix" pattern-to-strip="_TABLE,_VIEW"/>
 </conventions>
...
</enrichment>
 

Field naming convention

Field naming convention stripping

apply-strip-column-naming-convention convention will remove entity whose name start or end with a certain pattern.
In the following snippet
<enrichment>
...
 <conventions>
  <column-naming-convention type="apply-strip-column-name-suffix" pattern-to-strip="ID,PK">
  <column-naming-convention type="apply-strip-column-name-prefix" pattern-to-strip="FK_">
 </conventions>
...
</enrichment>

Field naming convention camelcase

apply-strip-column-naming-convention convention can also ensure that database object name using camel case are kept.
By default this is not the case since minuteproject considers that database name are uppercase + underscore. So your camel-case word will be converted into a language lower case variable and also for screen presentation.
If you work with database convention when you use camel case and you want to keep the same camel-case wording for variable and have human readable name when this variable is used for display purpose then set type="apply-field-alias-based-on-camelcase".
  <column-naming-convention type="apply-field-alias-based-on-camelcase" >

Table default primary key convention

When a table do not have a primary key but has a field that can work as a PK (such as a unique field) or just because on the schema the constraint is missing, there is a way to add this primary to the configuration.
In generator-config.configuration.model.business-model.enrichment.conventions add table-default-primary-key-convention node
Fill
  • type with apply-default-primary-key-otherwise-first-one
  • default-primary-key-names with the list of values that can correspond the name of the field that acts as primary-key. If no is filled or none is found than the first column will be considered as primary-key for entities without primary key.
      <table-default-primary-key-convention
          type="apply-default-primary-key-otherwise-first-one"
          default-primary-key-names="ID, PK"/>
 

View primary key convention

It works the same as table default primary key convention but for views.
View do not have primary-key but with this conventions you can attribute one
In generator-config.configuration.model.business-model.enrichment.conventions add view-primary-key-convention node
      <view-primary-key-convention
          type="apply-default-primary-key-otherwise-first-one"
           default-primary-key-names="ID, PK"/>

Detect relationship convention

This convention has the following type to detect foreign key:

autodetect-foreign-key-based-on-similarity-and-map

This convention parses all the entities' fields to check is there is a potential relationship.
If a field start or end with the value mentionned in column-starting or column-ending respectively
Then the inner part of the column is compared with the alias (by default entitty name) of the entity of the database.
If there is a match and if the types between the column and the pk of the compared entity then the column is considered as a fk.
      <foreign-key-convention
       type="autodetect-foreign-key-based-on-similarity-and-map"
       column-ending="id" column-starting="" />
 

autodetect-foreign-key-based-on-target-primary-key-name

This convention assumes that the foreign key are composed with the primary key name of the target entity.

Example
If table A (pk=A_ID, ...other field) and table B (pk=B_ID, ..., A_IDParentA)
The following convention
      <foreign-key-convention
       type="autodetect-foreign-key-based-on-target-primary-key-name"
       field-pattern-type="startsWith" />
 
Will consider A_IDParentA field of entity B as a foreign key pointing towards A.

Content type convention

This convention assigns to the entity referred the type of master data specified
<entity-content-type-convention type="apply-content-type-to-entity-starting-with" pattern="REF_" value="master-data"/>
<entity-content-type-convention type="apply-content-type-to-entity-ending-with" pattern="_CODE" value="master-data"/>
Here the configuration gives the content-type master-data to entities starting with REF_ or ending with _CODE.

Fix primary key convention

This convention assigns a fix value to a single-column primary-key when the proposed name do no collide with an existing variable.
<column-naming-convention type="apply-fix-primary-key-column-name-when-no-ambiguity" default-value="ID"/>
Here the configuration gives the alias ID to the primary key.

Semantic reference convention

This convention assigns a semantic reference to entities.
The entities being affected a semantic reference comes from:
  • a entity pattern selection (ex: entity-pattern = "REF_" pattern-type="startsWith")
    • pattern-type are:
      • startsWith
      • endsWith
      • contains
      • regex
  • a content-type (ex: content-type="reference-data")
  • a package (ex: package="admin")
  • if none of the above all entities are selected
For the selected entities, the semantic reference comes from the field pattern.
Semantic reference are supposed to be short, so the attribute max-number-of-fields limits the number of result. If not specified a default value of 3 is applied.
<semantic-entity-convention field-pattern="NAME,NUMBER" field-pattern-type="contains" max-number-of-fields="2"/>
The ordering is done by the pattern found first (here pattern 'field contains NAME' is applied first for all fields before 'field contains ORDER')

Here the configuration gives for
Entity A (FIRST_NAME, STREET_NUMBER, LAST_NAME, ZIP) gives a Semantic Reference A (FIRST_NAME, LAST_NAME)

To ensure there is always a match semantic entity convention as an boolean attribute force-default-semantic-reference-based-on-id-and-first-attribute-if-not-present, that ensure that there is a semantic reference for this entity. If nothing is found a default one based on the primary-keys and the first attribute found is provided.

Sometimes the semantic reference is composed of some field of the table itself and fields coming from a parent entity. To ensure that the convention propose the following attribute look-up-in-parent-for-match.

Nesting semantic-reference-conventions

Eventually, you can add this convention multiple times to match distinct pattern. Conventions are nested. So the semantic reference retrieved by the first convention will be appended with semantic entity element of the second one.
<semantic-entity-convention field-pattern="NAME" field-pattern-type="endsWith" max-number-of-fields="2"/>
<semantic-entity-convention field-pattern="NUMBER" field-pattern-type="contains" max-number-of-fields="1"/
Here the configuration gives for
Entity A (FIRST_NAME, NAME_OF_STREET, LAST_NAME, STREET_NUMBER, TEL_NUMBER, ZIP) gives a Semantic Reference A (FIRST_NAME, LAST_NAME, STREET_NUMBER).
TEL_NUMBER is not selected.
NAME_OF_STREET is not selected

Stereotype Convention

Stereotypes are attributes attached to fields that indicates mainly two things:
  • Implicit validation rule
  • Implicit rendering when displaying
This convention selects matching stereotype fields based on:
  • field-pattern
  • field-pattern-type
  • field-type
It assigns the convention type. Example email, currency, url, image, html-text
Example
<stereotype-convention
    field-pattern="currency" field-pattern-type="contains"
    stereotype="currency"/>
<stereotype-convention
    field-pattern="email" field-pattern-type="endsWith"
    stereotype="email"/>
<stereotype-convention
    field-type="BLOB" field-pattern="image" field-pattern-type="contains" override="true"
    stereotype="image"/>
<stereotype-convention
    field-type="CLOB" override="true"
    stereotype="text-html"/>


Business Model Configuration enrichment

Enrichment gives the possibility to add properties to entity, field, package. But also add global conventions.

Entity enrichment

Content type
In generator-config.configuration.model.business-model.enrichment.entity fill the following attributes:
  • name. This is the name of the entity
  • content-type. Possible value 'reference-data', 'pseudo-static-data', 'live-business-data'
In generator-config.configuration.model.business-model.enrichment.entity.semantic-reference add the following node
  • sql-path with attribute path. 'Path' begin the name of the field
Example
This snippet shows that entity Country is a reference data entity whose semantic reference is name. This information can be used to create Drop Down list, cache configuration, specific DAO queries, etc...
<entity name="COUNTRY" content-type="reference-data">
  <semantic-reference>
    <sql-path path="NAME"/>
  </semantic-reference>
</entity>

Field enrichment

Constraint
Indicate that a field can contain only a specific set of values.
In generator-config.configuration.model.business-model.enrichment.entity.field fill the following attributes:
  • name
In generator-config.configuration.model.business-model.enrichment.entity.field.property fill the following attributes:
  • tag with 'checkconstraint'
  • name with 'checkconstraint' (remark: It is a little redundant)
  • a list of property filled with attribute
    • name holding the distinct values.
Example
This snippet shows that the field 'STATUS' of the entity 'ACTIVITY_STATUS' can have the values 'Active', 'Closed', 'Rejected', 'Archived'. This information can be used to create Drop Down list; type check, check constraints, specific DAO queries, etc..

<entity name="ACTIVITY_STATUS" >
 <field name="STATUS">
  <property tag="checkconstraint" name="checkconstraint">
   <property name="Active" />
   <property name="Closed" />
   <property name="Rejected" />
   <property name="Archived" />
  </property>
 </field>
</entity>

Adding a primary key (release 0.5)
Indicate that a field can be considered as a Primary key.
This enrichment is mainly used for views, where there is no primary key at the database meta information level. Meanwhile some framework/specification might need to have on field playing this role.

In generator-config.configuration.model.business-model.enrichment.entity.virtual-primary-key fill the following attributes:
  • isRealPrimayKey to 'true'
In generator-config.configuration.model.business-model.enrichment.entity.virtual-primary-key.property fill the following attributes:
  • name to 'virtualPrimaryKey
  • value to the name of the entity field.

This snippet shows that a field in the entity 'VW_BUSINESS_OVERVIEW' whose name is 'ID' can be considered as a primary key (ensure that is it unique).
<entity name="VW_BUSINESS_OVERVIEW" >
 <virtual-primary-key isRealPrimaryKey="true">
  <property name="virtualPrimaryKey" value="ID"/>
 </virtual-primary-key>
</entity>

Adding a foreign key (release 0.5)
Indicate that a field can be considered as a Foreign key.
This enrichment is mainly used for views, where there is no foreign key at the database meta information level.

In generator-config.configuration.model.business-model.enrichment.entity.field fill the following attributes:
  • name to the name of the field
  • linkToTargetEntity to the name of the target entity
  • linkToTargetField to the name of the field of the target entity (usual the target entity primary key).

This snippet shows that a field in the entity 'VW_BUSINESS_DETAIL' has a foreign key that points to 'VW_BUSINESS_OVERVIEW'.

<entity name="VW_BUSINESS_OVERVIEW" >
 <virtual-primary-key isRealPrimaryKey="true">
  <property name="virtualPrimaryKey" value="ID"/>
 </virtual-primary-key>
</entity>
<entity name="VW_BUSINESS_DETAIL" >
 <virtual-primary-key isRealPrimaryKey="true">
  <property name="virtualPrimaryKey" value="ID"/>
 </virtual-primary-key>
 <field name="OVERVIEW_ID" linkToTargetEntity="VW_BUSINESS_OVERVIEW" linkToTargetField="ID" ></field>
</entity>


Target technologies

This part describes how to add a target technology. The main configuration file reference another file which hold all the information regarding the entire set of templates and their metadata.

Referencing a target technology

There are two ways to reference a target technology:
  • via catalog
  • by referencing template metadata
The first is to be used when using Minuteproject distribution as-is. Choose technology that are part of the distribution.
The second is to be used (can be complementary to the first one) when you want more specific generation with your own template sets composition.
In fact the catalog target is a composition of template set labeled under a technology entry.

Catalog technology

In generator-config.configuration.targets at the following 'target' nodes
Target node has the following attribute
  • catalog-entry required if you do not know which track to specify, put blank and at the first run minuteproject will propose all the tracks available.
  • outputdir-root is optional, if you not set your code will be generated in ../output directory
<targets catalog-entry="JPA2" outputdir-root="somewhere/on/your/drive" />
 
Multiple catalog entries can be generated in one row
<targets catalog-entry="JPA2,OpenXava,Primefaces-Spring"  />

Specific technology composition

In generator-config.configuration.targets at the following 'target' nodes
For each target in generator-config.configuration.targets.target fill the following attributes:
  • name
  • fileName to the target template configuration file
  • outputdir-root to the place in the file system where the generation output will go
  • templatedir-root to the place in the file system where the templates are located
Normally the only information to adapt is outputdir-root.

Example:
This snippet shows the target configuration to generate for OpenXava technology.
<targets>
 <target name="OpenXava"
 fileName="mp-template-config-openxava-last-features.xml"
 outputdir-root="../../dev/openxava/myBusinessConsole"
 templatedir-root="../../template/framework/openxava">
</target>
<target refname="LIB"
fileName="mp-template-config-bsla-LIB-features.xml"
 outputdir-root="../../DEV/output/padmeConsole"
templatedir-root="../../template">
</target>
</targets>


.