Get those Maven Warnings out of here

This article shows why ignoring Maven plugin version warnings can break every build when an incompatible plugin release appears. It demonstrates how `pluginManagement` in a root or corporate POM prevents that risk by pinning stable versions across projects.

Coveros Staff

November 26, 2015

 

[WARNING] Some problems were encountered while building the effective model for GoodPom:GoodPom:jar:1.0-SNAPSHOT
[WARNING] ‘build.plugins.plugin.version’ for org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 19, column 15
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.

I have been working with a client that has a complex maven project. Every time a build is started a bunch of warnings similar to the one above is written out. But they are only warnings so they have been ignored.

The great thing about maven is that it wants to help you. It is telling you exactly which plugin is not properly specified and the consequences. If you don’t give it the right instructions it will do stuff you probably didn’t consider. The perfect example stopped all development for my client for a day. And It could have easily been avoided.

<build>
 <plugins>
   <plugin>
     <groupId>org.codehaus.mojo</groupId>
     <artifactId>build-helper-maven-plugin</artifactId>
   </plugin>
 </plugins>
</build>

Plugin Version Management

A maven plugin similar to the one above released a new version a couple days ago. That is great! Except that the project requires JDK 1.6 and the new version of the plugin requires JDK 1.7.

The problem is that when the maven plugin was used no one ever specified a version so maven says “Fine! I’m going to use the latest version!”. Which it did. So guess what happens? Every build for every project now is broken. No one can build. Developers can’t build. Jenkins can’t build.

How could this have been avoided? By leveraging Maven’s configuration management.

Maven solves this problem with plugin management and dependency management. At the root pom or at a Corporate Pom you define the plugin version and then it is available to everyone at a standardized version. Now everyone is set to a defined version of the plugin that we know works for our project.

<build>
 <plugins>
   <plugin>
     <groupId>org.codehaus.mojo</groupId>
     <artifactId>build-helper-maven-plugin</artifactId>
   </plugin>
 </plugins>
 <pluginManagement>
   <plugins>
     <plugin>
       <groupId>org.codehaus.mojo</groupId>
       <artifactId>build-helper-maven-plugin</artifactId>
       <version>1.9.1</version>
     </plugin>
   </plugins>
 </pluginManagement>
</build>
Coveros Staff

Coveros Staff

This post represents the collective insights of the Coveros team. Our staff consists of software experts who bring deep experience in secure agile development, DevOps, testing, and software quality. Over the past 20 years, Coveros has trained more than 30,000 professionals and worked with half of the Fortune 100 companies on mission-critical software development challenges. We draw on this extensive experience to share practical insights, proven strategies, and real-world solutions that help organizations build better software faster and more securely.