May 4, 2009

Maven Enforcer Plugin: cool and annoying

As a Maven expert, you probably have heard of maven-enforcer-plugin, "The Loving Iron Fist of Maven", as they say.

It's so cool!

The idea is pretty cool: the plugin provides goals to ensure that the environment used to run Maven is like you – the POM author – expected it to be. There are checks for constraints on the version of Maven or JDK, on the OS family, to enforce certain dependency requirements, and much more. This list on the web site gives you an impression on what kind of checks are provided.

Do you know what happens when you write your POMs and settings for Maven version 2.0.9 or greater, but somebody is still using an outdated 2.0.4? Well, this kind of issues is annoying and you better make sure it does not happen.

The current version of maven-enforcer-plugin (at the time we set it up) was 1.0-alpha-4 which sounded not very mature, but nevertheless we decided to use it. For our projects, we identified a couple of things we wanted to check, and we configured the plugin accordingly:

  • Java Version: should be 1.5.
  • Maven version: must at least be 2.1.0.
  • Enforce defined versions for all plugins, and disallow any use of "LATEST", "RELEASE" or "SNAPSHOT" as a version for any plugin.

Hey, SNAPSHOT plugins are just dangerous and you should never, never ever depend on them. The only exclusion could be plugins developed inhouse, but actually, no – not really. Bah, don't use SNAPSHOT plugins. Period.

So, we tried to setup our enforcer plugin configuration like this:

<plugin>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.0-alpha-4</version>
<executions>
<execution>
<id>enforce-versions</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireMavenVersion>
<version>[2.1.0,)</version>
</requireMavenVersion>
<requireJavaVersion>
<version>1.5</version>
</requireJavaVersion>
<requirePluginVersions>
<message>Best Practice is to always define plugin versions!</message>
<banLatest>true</banLatest>
<banRelease>true</banRelease>
<banSnapshots>true</banSnapshots>
</requirePluginVersions>
</rules>
</configuration>
</execution>
</executions>
</plugin>
Of course, we wanted to apply the same checks on command line as within Eclipse when using m2eclipse plugin.

It's so annoying!

Well, and here is where the trouble started...

Shot one. Oh, wait, we are using Maven version 2.1.0-M1 currently. Guess what? This is not included in range [2.1.0,) which means every version x >= 2.1.0. Okay. Let's use [2.1.0-M1,) instead.

Shot two. What about Eclipse? The check fails within Eclipse, and it turns out that the version number reported by the Maven embedder used by m2eclipse (0.96 at that time) is 2.1-SNAPSHOT. Thus, enforcer fails and we'll have to use this for the Maven version specification:

<version>[2.1.0-M1,),[2.1-SNAPSHOT,)</version>

Ugly, but still manageable...

Shot three. My team reported the enforcer plugin to sometimes use some "thinking time" when checking the environment – it seems to hang for couple of seconds. We all see that betimes, and I have no idea what it is caused by. Actually, performing those version checks should be fast as light, right?

What makes this even worse is the fact that in multi-module builds, enforcer plugin is called for each subproject. It binds by default to the validate lifecycle phase which is executed for every subproject. However, the environment does not change very much during a single build, so it would be sufficient to check that only once per Maven call...

Shot four. When establishing the cool Sonar quality management platform, Maven started to complain that "some plugins are missing valid versions". Seems that Sonar defines dependencies to other artifacts used internally, but doesn't give a version for them. All you can do is specify a version for those plugins in the <pluginManagement> section of one of your parent POMs. That's actually not what you want: explicitely list versions for artifacts used internally by the current version of a build tool... But what else can you do? Completely disable the requirePluginVersions check?

Shot five. After upgrading m2eclipse to version 0.97, it does not correctly handle our enforcer configuration any more and instead yields an error:

org.apache.maven.lifecycle.LifecycleExecutionException: Invalid or missing parameters: [Mojo parameter [name: 'rules'; alias: 'null']] for mojo: org.apache.maven.plugins:maven-enforcer-plugin:1.0-alpha-4:enforce

This is a known issue, and you have to uncheck the "Skip Maven compiler plugin when processing resources" checkbox in the project's properties. That means, we have to change configuration for all our projects :-(

Moreover, it was the default to check this option and it seems to have negative performance impact when deselected.

Game over. This is the point where we eliminated enforcer plugin. Too much pain for a little helper tool. One of those things that seems to be quite cool at first glance, but starts to annoy you very soon.

6 comments:

  1. Yes, unfortunately this is a known issue. However, the M2Eclipse JIRA moved from codehaus.org to isses.sonatype.org. The updated bug can be found here:
    https://issues.sonatype.org/browse/MNGECLIPSE-1091

    There is a workaround for this issue in the URL above. We are planning on fixing this properly for the 0.9.9 release.

    ReplyDelete
  2. Rich, thanks for the hint, I've fixed the link. I didn't know Sonatype is taking the Jiras home to their domain ;-)

    ReplyDelete
  3. Maven will execute a plugin for all children, there isn't much a plugin can do about that. What the enforcer does do however is cache results of the rules and rules can decide if they need to be rerun. Obviously things like checking the Maven version don't...but the plugin still gets executed by Maven. I'm not sure what this thinking time is about, but some -X debug logs might tell you. I'm betting that it's Maven thinking prior to invoking the plugin.

    Specifically for the requirePluginVersions rule, you can specify a list of plugins to not check. Look for unCheckedPluginsList on http://maven.apache.org/enforcer/enforcer-rules/requirePluginVersions.html

    In .9.9, the M2e embedder will be updated to 3.0-beta-x and it will solve some of the problems with it executing inside Eclipse. For now you can move the configuration outside the execution as this specifically is dropped in one of the embedder actions which causes the problems you see.

    ReplyDelete
  4. Brain, thanks for your tips. I seem to have overlooked the unCheckedPluginsList option, this definitely would have helped.

    Glad to hear enforcer implementation is doing what it can to speed up the checks. We tried to use -X to find out what is causing the pause, but it seemed the debug output was retarding the build in a way the "enforcer thinking time" was not evident any more.

    At the time I did the investigations we also had the display-info goal activated which I did not mention in my post, maybe that was actually causing it. When testing for a project with 6 children, just calling validate phase without enforcer took around 5 sec. and with enforcer (calling both goals, display-info and enforce) it took usually 15 sec., but sometimes 20-25 sec. -- meaning an overhead of 10 sec. (which is fine) and additionally a "delay" of 5-10 sec. for one of the projects sometimes. Yeah, not really much, but nevertheless people complained...

    Also, for m2e we tried to move the configuration out of the execution but then it seemed the rules never caused the build to fail. However, I can't reproduce this any more with current version 0.9.8 of m2e, it correctly checks and fails the build. So I can't tell if this was due to other version of m2e or something else in our configuration...

    ReplyDelete
  5. One thing to note on the "delay". The enforcer asks maven to resolve all dependencies before it executes. This would happen anyway in a later phase. The point being that the apparent delay in the validate phase may actually have been a delay just moved up from the compile phase.

    ReplyDelete
  6. Yep, that indeed could be the reason. Projects defined snapshot dependencies that could cause a lookup one or the other time. As I said before, even if it was 10 secs. of additional time, it shouldn't make much difference for the total build/test/deploy time which was around 6 min. It's just that people wondered about...

    ReplyDelete