Automation Series #7 – Build Lifecycle

The build lifecycle is the central concept of Maven. After everything we covered in previous articles, these few commands will guide us through the build process. Thereby we can transform every manual step of build, test, and package to an automated one to be used by an integration tool. Wow! This is awesome. Imagine a robot doing every stressful step we used to do by clicking a single button or after each commit. Great!

Build Lifecycle Types

Maven has some built-in lifecycles that each one has a specific list of phases executed in order. You can check the complete reference here.

default: handles the project deployment with phases representing each stage of a software lifecycle.
clean: phases to help on the project cleanup.
site: phases to generate the project site documentation.

Default Lifecycle

There are about 23 phases at this lifecycle. Many of them are for processing and generating resources for the next phases. So let’s cover the most commonly used ones for daily development. You may see that all of them have very intuitive names.

validate: the first phase checks all necessary information.
compile: after all processed and generated resources, it compiles the source code.
test: after having processed and generated resources, but now being specific for tests, it performs the tests of the already compiled source code by a unit testing framework.
package: does the package of the compiled source code with the configured distribution format, such as WAR or JAR. After this phase, you may perform integration tests that require a package for it.
verify: checks the test results to ensure software pre-established quality criteria, failing the process if they don’t match.
install: install the artifact (WAR, JAR, … ), its POM, sources, javadocs, and any other attached file into the local repository to be used as a dependency to local projects.
deploy: installs the project to a remote repository to be used by other developers. Generally done on release environments.

Clean Lifecycle

At the simplest way, a single command to delete the target folder. The clean command deletes the build and output build, test and reporting directories. So even with an overwritten location configuration, Maven cleans generated resources in a right way.

Another useful usage is deleting specific files such as logs and temporary files generated by your project. Check a Maven documentation example here.

Site Lifecycle

The Site Maven Plugin used by this lifecycle has multiple goals. But only two of them are attached to direct commands. site command generates the site project and site-deploy deploys the generated site according to POM configurations.

The site goal could be attached to a specific build phase avoiding the extra command. But keep it in mind that it will make your build process slower. The example attaches the site generation to package phase.

<build>
  [...]
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-site-plugin</artifactId>
    <version>3.6</version>
    <executions>
      <execution>
        <phase>package</phase>
        <goals>
          <goal>site</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
  [...]
</build>

Without the previous POM configuration, these combined commands will produce the same result.

mvn package site

Customizing

Most of the times you will overwrite some configurations on at least one of these phases. Considering that the default source and target Java Compiler is 1.5 version, you maybe need to change it. According to the documentation, there are two simple ways to do this.

Overwriting the plugin properties names:

<project>
  [...]
  <properties>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
  </properties>
  [...]
</project>

Or configure the plugin directly:

<project>
  [...]
  <build>
    [...]
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.7.0</version>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
        </configuration>
      </plugin>
    </plugins>
    [...]
  </build>
  [...]
</project>

You can also override behaviors via the command line. Maven has the flexibility to run multiple phases with parameters changing specific behaviors. Here is an example of cleaning previously generated resources, packaging the source code and avoiding tests.

mvn clean package -DskipTests

Next Step

As we saw, almost everything on Maven is based on plugins. So our next step will cover plugin features.

Let’s automate!