Maven - Dealing with Plugins

After many articles talking about theory, it’s time to get started. Maven is all based on Plugins. So if you want to change any project behavior, you will need to overwrite some plugin properties or attach new ones.

A highly requested concept to deal with plugins is Maven phases. Check the build lifecycle article to understand it better and feel more confident.

Plugins

As most of Maven configurations, the minimal plugin setup is groupId, artifactId and version tags. You can search for them in the same way as the dependencies at MVN Repository.

Maven is – at its heart – a plugin execution framework; all work is done by plugins. — Apache Maven Project

As the quote says, everything is pluggable. Even Maven base installation is based on plugins. So all Maven projects extend the main configuration, known as Super POM. The result of this merged configuration is known as effective-pom. Even the simplest project has a huge default configuration behind the scenes. Check yours using this command (on project root folder followed by your pom file):

mvn help:effective-pom

The good news is that you can change any of this pre-established plugin behavior. This Maven model page may help you a lot as well as it helped me. It is a deep documentation reference to search for available tags that could solve your problem.

Build

There are some configurations used in most of the cases that are important to know.

  • <executions>: Define multiple goals specifications to run during the build lifecycle.
    • <id>: Great label identifier during the build but very useful to configure profiles.
    • <phase>: The build lifecycle phase that you want to bind the set of goals of this execution.
    • <goals>: The plugin goals that you want to execute.
  • <configuration>: List of key and value tags expected by the plugin.
  • <dependencies>: Additional dependencies to fulfill the plugin needs. Or a good way to override a plugin dependency to use a more recent version.

In the last article, we have already seen how to link a site generation to a specific phase and override maven compiler using configuration tags. Let’s cover a different one, how about cleaning the project before every compilation?

If you always need to run the clean phase before any other phase, this configuration could avoid this extra step.

<project>
  [...]
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-clean-plugin</artifactId>
        <version>3.0.0</version>
        <executions>
          <execution>
            <id>auto-clean</id>
            <phase>initialize</phase>
            <goals>
              <goal>clean</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
  [...]
</project>

This example was extracted from Clean Plugin usage page.

Report

Report configuration is a great way to create automated documentation to your project. By default, running site target, you can create a basic documentation without any effort.

What about javadocs and source being automatically generated and attached to the project site? Easy! Just configure it once.

<reporting>
  [...]
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-javadoc-plugin</artifactId>
      <version>2.10.4</version>
    </plugin>

    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jxr-plugin</artifactId>
      <version>2.5</version>
    </plugin>
  </plugins>
  [...]
</reporting>

It is very similar to configure javadocs and sources to be automatically generated with the application package. Follow this Maven cookbook.

Here is an extra golden tip to Java 8 users. doclint is a tool added to Javadoc aiming some W3C standards. But it may break your Javadoc output. Take a look at this article to understand it better. You will need to make an extra configuration to avoid this annoying error before fixing these doclint problems.

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-javadoc-plugin</artifactId>
  <version>2.10.4</version>
  <configuration>
    <additionalparam>-Xdoclint:none</additionalparam>
  </configuration>
</plugin>

Next Step

We have just covered a small piece of plugins, but you can configure many others. There are plugins for building code, generating tests and controlling quality reports, and so on. Some of the most known are Jacoco, Surefire and PMD. According to the needs of your project, you can use any type of plugin combinations.

Our next and last stop on this build automation series will be dealing with repositories.

Let’s automate!


Leave a Reply

Your email address will not be published.