1. Overview
In this tutorial, we’re going to learn about the Maven Enforcer Plugin and how we can use it to guarantee the level of compliance in our project.
The plugin is especially handy when we have distributed teams, scattered across the globe.
2. Dependency
To make use of the plugin in our project, we need to add the following dependency to our pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>3.0.0-M2</version>
</plugin>
The latest version of the plugin is available on Maven Central.
3. Plugin Configuration and Goals
Maven Enforcer has two goals: enforcer:enforce and enforcer:display-info.
The enforce goal runs during a project build to execute rules specified in the configuration, while the display-info goal shows current information about the built-in rules that are present in the project’s pom.xml.
Let’s define the enforce goal in the executions tag. Furthermore, we’ll add the configuration tag that holds the rules definitions for the project:
...
<executions>
<execution>
<id>enforce</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<banDuplicatePomDependencyVersions/>
</rules>
</configuration>
</execution>
</executions>
...
4. Maven Enforcer Rules
The keyword enforce gives a subtle suggestion of the existence of rules to abide by. This is how the Maven Enforcer plugin works. We configure it with some rules that are to be enforced during the build phase of the project.
In this section, we’re going to look at the available rules that we can apply to our projects to enhance their quality.
4.1. Ban Duplicate Dependency
In a multi-module project, where a parent-child relationship exists among POMs, ensuring there’s no duplicate of dependency in the effective final POM for a project can be a tricky task. But, with the banDuplicatePomDependencyVersions rule, we can easily make sure that our project is free of such glitch.
All we need to do is to add the banDuplicatePomDependencyVersions tag to the rules section of the plugin configuration:
...
<rules>
<banDuplicatePomDependencyVersions/>
</rules>
...
To check the rule’s behavior, we can duplicate one dependency in pom.xml and run mvn clean compile. It’ll produce the following error lines on the console:
... [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanDuplicatePomDependencyVersions failed with message: Found 1 duplicate dependency declaration in this project: - dependencies.dependency[io.vavr:vavr:jar] ( 2 times ) [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1.370 s [INFO] Finished at: 2019-02-19T10:17:57+01:00 ...
4.2. Require Maven and Java Version
The requireMavenVersion and requireJavaVersion rules enable a project-wide lock-in of required Maven and Java versions, respectively. This will help eliminate the disparity that might arise from using different versions of Maven and JDK in development environments.
Let’s update the rules section of the plugin configuration:
<requireMavenVersion>
<version>3.0</version>
</requireMavenVersion>
<requireJavaVersion>
<version>1.8</version>
</requireJavaVersion>
These allow us to specify the version numbers in a flexible manner, as long as they comply with the plugin’s version range specification pattern.
Furthermore, both rules also accept a message parameter for specifying a custom message:
...
<requireMavenVersion>
<version>3.0</version>
<message>Invalid Maven version. It should, at least, be 3.0</message>
</requireMavenVersion>
...
4.3. Require Environment Variable
With the requireEnvironmentVariable rule, we can ensure that a certain environment variable is set in the execution environment.
It can be repeated to accommodate more than one required variable:
<requireEnvironmentVariable>
<variableName>ui</variableName>
</requireEnvironmentVariable>
<requireEnvironmentVariable>
<variableName>cook</variableName>
</requireEnvironmentVariable>
4.4. Require Active Profile
Profiles in Maven help us to configure properties that’ll be active when our application is deployed to different environments.
Consequently, we can use the requireActiveProfile rule when we need to ensure that one or more specified profiles are active, thus guaranteeing the successful execution of our application:
<requireActiveProfile>
<profiles>local,base</profiles>
<message>Missing active profiles</message>
</requireActiveProfile>
In the snippet above, we used the message property to provide a custom message to show if the rule-check fails.
4.5. Other Rules
The Maven Enforcer plugin has many other rules to promote project quality and consistency irrespective of the development environment.
Also, the plugin has a command to display info about some currently configured rules:
mvn enforcer:display-info
5. Custom Rules
So far, we’ve been exploring the built-in rules of the plugin. Now, it’s time to look at creating our own custom rule.
First, we need to create a new Java project that’ll contain our custom rule. A custom rule is a class Object that implements the EnforceRule interface and overrides the execute() method:
public void execute(EnforcerRuleHelper enforcerRuleHelper) throws EnforcerRuleException {
try {
String groupId = (String) enforcerRuleHelper.evaluate("${project.groupId}");
if (groupId == null || !groupId.startsWith("org.baeldung")) {
throw new EnforcerRuleException("Project group id does not start with org.baeldung");
}
}
catch (ExpressionEvaluationException ex) {
throw new EnforcerRuleException( "Unable to lookup an expression "
+ ex.getLocalizedMessage(), ex );
}
}
Our custom rule simply checks if the target project’s groupId starts with org.baeldung or not.
Notice how we don’t have to return boolean or anything as such to indicate the rule is not satisfied. We just throw an EnforcerRuleException with a description of what is wrong.
We can use our custom rule by adding it as a dependency to the Maven Enforcer plugin:
...
<rules>
<myCustomRule implementation="com.baeldung.enforcer.MyCustomRule"/>
</rules>
...
Please note that if the custom rule project is not a published artifact on Maven Central, we can install it into the local Maven repo by running the mvn clean install.
This will make it available when compiling the target project that has the Maven Enforcer Plugin. Please see the plugin’s documentation for the custom rule to learn more.
To see it in action, we can set the groupId property of the project with the Enforcer Plugin to anything other than “org.baeldung” and run mvn clean compile.
6. Conclusion
In this quick tutorial, we saw how the Maven Enforcer Plugin can be a useful addition to our existing chest of plugins. The ability to write custom rules enhance its range of application.
Please note that we need to uncomment the dependencies and rule for the custom-rule example in the complete example source code that’s available over on GitHub.