Maven automation and continuous development cycle

Every MADS module is a Maven project that inherits from the platform parent POMs. That is why modules build the same way on any machine, and the commands you use locally are the same ones you use on a continuous integration server.

Module structure

A new module created with mads create module has a POM like this:

<parent>
  <groupId>madsv5</groupId>
  <artifactId>mads-module</artifactId>
  <version>5.1.0</version>
</parent>

<groupId>madsv5.module</groupId>
<artifactId>invoicing</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>

<dependencies>
  <dependency>
    <groupId>madsv5</groupId>
    <artifactId>mads-jpalib</artifactId>
    <version>5.1.0</version>
  </dependency>
  <dependency>
    <groupId>madsv5.module</groupId>
    <artifactId>security</artifactId>
    <version>5.1.0</version>
  </dependency>
  <dependency>
    <groupId>madsv5</groupId>
    <artifactId>mads-jtest</artifactId>
    <version>5.1.0</version>
    <scope>test</scope>
  </dependency>
</dependencies>

mads-module (or mads-service for web services) provides the shared build configuration.
platform, the parent of both, pins dependency versions so every module uses the same ones.
Dependencies between modules are plain Maven dependencies: Maven resolves them and tells you when one is missing.

The lifecycle of a change

Step	Command	What it does
Generate	`mads generate module`	Regenerates the Java model, texts and parameters from the metadata
Test	`mads module test`	Runs the module tests
Build	`mads module build`	Compiles, packages and installs into the local Maven repository
Version	`mads module version`	Updates the module version
Deploy	`mads module deploy`	Publishes the artifact to the Maven repository
Publish	`mads pub module` / `mads pub app`	Publishes the module or app to the WAPP service

For an app, mads app version and mads app update do the equivalent.

The module commands accept --modulePath to work on a module from any folder, which makes them easy to automate.

Continuous integration

A typical pipeline runs the same cycle on every change pushed to the repository. For example, in a CI script:

export MADS_NO_UPDATE_CHECK=1          # no version check on the server
export M2_HOME=/opt/maven

# 1. (Optional) Generated code must match the metadata
mads generate module --modulePath .
git diff --exit-code                   # fails if someone forgot to regenerate

# 2. Tests and build
mads module test --modulePath .
mads module build --modulePath .

# 3. Main branch only: deploy
mads module deploy --modulePath .

Step 1 is optional and requires the generated code to be committed and the generation to be stable (no dates or reordering between runs; check by running it twice). When that holds, it guarantees nobody pushes metadata without the regenerated code, or the other way round.

Good practices

One version per release. Use mads module version before deploying and never deploy the same version twice.
Depend on modules by version, not by copy. If a module needs another one, declare the dependency in the POM; do not copy its classes.
Tests with mads-jtest. Extend its base test cases to test against a real development database.
Review the generated code. It is part of the repository and of every change review.

See every option in the mads reference.