In projects with many parent POMs, profiles, and plugin management sections, one can easily end up in a situation where the effective configuration for a plugin is the result of merging many configuration blocks from the various POM sources together.

Not knowing the details of this merge process naturally leads to some confusion about why an effective configuration looks the way it looks, or why changes to some parent POM’s configuration don’t have the desired effects in child POMs.

This post attempts to shed some light on this confusion, and provides you with a sense of how Maven merges plugin configuration from multiple sources.   This post uses attributes which are available in Maven 3.0.2.

The Simplest Case: Merging Parent and Child POMs

As a concrete example, let’s assume we have a parent POM with the following plugin configuration:

Let’s further assume we have a child POM that inherits from the above parent and that specifies the following configuration for the same plugin:

Now, as an invocation of mvn help:effective-pom will show you, the effective plugin configuration for the child project will be:

This result demonstrates the default merge behavior. The configuration elements are recursively merged based on the element name, and elements from the parent POM are only added to the result when the child POM does not contain an equally named element. Let me stress that merging of plugin configuration is purely an operation on the XML DOM tree. In particular, the merge process has no knowledge of the actual data structures in the plugin that will be configured nor their semantics. In other words, configuration values are generally not considered as merge keys when combining child and parent elements, only the name of the configuration elements is used to identify conflicting elements that need to be merged.

Controlling the Merge Process with combine.children and combine.self

Sometimes the default merge behavior doesn’t produce the intended configuration. In this case, one can use two attributes on the child configuration to adjust the behavior as shown in the next child POM:

Assuming the above child POM still inherits from the previously sketched parent POM, one would now get the following effective configuration:

As you can see here, usage of combine.children="append" results in the concatenation of parent and child elements, in that order. The attribute combine.self="override" on the other hand completely suppresses parent configuration to be inherited. That said, it’s senseless to specify both combine.self="override" and combine.children="append" for a configuration element, the former directive takes precedence.

Note that these attributes only apply to the configuration element they are declared on, and are not propagated to nested elements. That is if the <item> element from our last child POM would be a complex structure instead of a mere string, its sub elements would still be subject to the default merge strategy.

The combine.* attributes are however inherited along a hierarchy of POMs. So some care must be taken when adding those attributes to a configuration snippet in a parent POM as this might affect child or grand-child POMs unless those explicitly override the attributes themselves.

Last but not least, please note that the attributes described here to control merging only apply to plugin configuration. You cannot use these attributes on other elements of the POM.

One of the key things driving the adoption of Maven, is the rich set of plugins available. Whenever you want to add some functionality to the build process, or possibly even just want to do a one-time job, chances are that there is already a plugin for that.

When you want to use Maven plugins, you need to get more information about them to know how to use them. Most often, there is online documentation that describes the goals and parameters. However, sometimes no such documentation exists or you just cannot find it. Also, the online documentation very often describes the latest version of the plugin – but what if you have to use an older version?

This blog post will explain the different options you have to retrieve information about a plugin, just by using Maven itself.

As mentioned above, the simplest way of viewing a plugin’s documentation is to use the one provided online. Not only does this documentation describe the available goals and the plugin’s parameters, but it most often also provides examples and other useful information. If available, this should normally be your first choice. However, there are at least two other ways of retrieving information from a plugin about it’s goals and parameters. These come in handy when there is no other documentation, and also when you want to be sure to find the goals and parameters of a specific version of the plugin.

The first option, and most likely the easiest one to remember, is to use the help goal of the plugin itself. Here’s an example:

mvn compiler:help

This would give you an overview of the goals of the Maven Compiler Plugin. If you want more information, add the detail parameter:

mvn compiler:help -Ddetail

If you want to focus on a specific goal, you do that through the goal parameter:

mvn compiler:help -Ddetail -Dgoal=compile

Please note that this will describe the version of the plugin according to normal Maven plugin management. To override that, there is always the option of specify the plugin version through the standard Maven syntax.

mvn org.apache.maven.plugins:maven-compiler-plugin:2.3:help -Ddetail -Dgoal=compile

Another great thing about the help goal is that it is created by Maven Plugin Plugin. So you could very easy add this feature to your own plugin as well, only by adding a simple POM configuration. However, this dependency is also the drawback. The functionality in Maven Plugin Plugin was added in version 2.4, so plugins (or older versions of plugins) written before that would not have the help goal. Fortunately, there is another option for those cases.

A fallback option is to use the Maven Help Plugin and its describe goal. It will work with any version of a plugin you want to describe. As an example, here is the equivalent to the one above:

mvn help:describe -Dplugin=org.apache.maven.plugins:maven-compiler-plugin:2.3 -Ddetail -Dmojo=compile

As this feature is described in detail in chapter 6.3.1 of Maven: The Complete Reference and also in the online documentation of Maven Help Plugin, I will not go into more details about it.

Try the different options and see which one you prefer. Please note that even if they provide much of the same information there are some slight differences. In some areas, like information about default phase binding, I find the help:describe option more informative.

One of the key things driving the adoption of Maven, is the rich set of plugins available. Whenever you want to add some functionality to the build process, or possibly even just want to do a one-time job, chances are that there is already a plugin for that.

When you want to use Maven plugins, you need to get more information about them to know how to use them. Most often, there is on-line documentation that describes the goals and parameters. However, sometimes no such documentation exists or you just cannot find it. Also, the on-line documentation very often describes the latest version of the plugin – what if you have to use an older version?

I recently faced a closed-source plugin, with no documentation. This blog post will explain the different options you have to retrieve information about a plugin, just by using Maven itself.

As mentioned above, the simplest way of viewing a plugin’s documentation is to use the one provided on-line. Normally in HTML and created by the Maven Site Plugin, this is what we have got used to with most open source plugins.

Not only does this documentation describe the available goals and its parameters, but it most often also provides examples and other useful information. If available, this should normally be your first choice. However, there are at least two other ways of retrieving information from a plugin about it’s goals and parameters. These come in handy when there is no other documentation, but also when you want to be sure to find the goals and parameters of a specific version of the plugin.

The first option, and most likely the easiest one to remember, is to use the help goal of the plugin itself. Here’s an example:

mvn compiler:help

This would give you an overview of the goals of the Maven Compiler Plugin. If you want more information, add the detail parameter:

mvn compiler:help –Ddetail

If you want to focus on a specific goal, you do that through the goal parameter:

mvn compiler:help –Ddetail –Dgoal=compile

Please note that this will describe the version of the plugin according to normal Maven plugin management. To override that, there is always the option of specify the plugin version through the standard Maven syntax.

mvn org.apache.maven.plugins:maven-compiler-plugin:2.3:help -Ddetail -Dgoal=compile

Another great thing about the help goal is that it is created by Maven Plugin Plugin. So you could very easy add this feature to your own plugin as well, only by adding a simple POM configuration.

However, this dependency is also the drawback. The functionality in Maven Plugin Plugin was added in version 2.4, so plugins (or older versions of plugins) written before that would not have the help goal. Fortunately, there is another option for those cases.

A fallback option is to use the Maven Help Plugin and its describe goal. It will work with any version of a plugin you want to describe. As an example, here is the equivalent to the one above:

mvn help:describe -Dplugin=org.apache.maven.plugins:maven-compiler-plugin:2.3 -Ddetail -Dmojo=compile

As this feature is described in detail in chapter 6.3.1 of Maven: The Complete Reference and also in the on-line documentation of Maven Help Plugin, I will not go into more details about it.

Try the different options and see which one you prefer. Please do note that even if they provide much the same info, there are some slight differences. In some areas, like information about default phase binding, I find the help:describe option more informative.

It’s been a while since I posted, so here’s a quick and dirty code by example:

If you want to make a standalone jar (ie one with no dependencies) executable, here’s how you do it:

<pluginManagement>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jar-plugin</artifactId>
        <configuration>
          <archive>
            <manifest>
              <addClasspath>true</addClasspath>
              <mainClass>com.yourcompany.YourClass</mainClass>
            </manifest>
         </archive>
       </configuration>
    </plugin>
  </plugins>
</pluginManagement>

If however you have dependencies, you will probably want to bundle them into a single jar, otherwise making it executable is not very helpful. You can use the assembly plugin to do it like this:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-assembly-plugin</artifactId>
    <executions>
      <execution>
         <goals>
           <goal>attached</goal>
         </goals>
         <phase>package</phase>
         <configuration>
           <descriptorRefs>
             <descriptorRef>jar-with-dependencies</descriptorRef>
          </descriptorRefs>
          <archive>
            <manifest>
              <mainClass>com.yourcompany.YourClass</mainClass>
            </manifest>
          </archive>
        </configuration>
     </execution>
  </executions>
</plugin>

A few comments:

1. I didn’t specify plugin versions in the example. You should always specify a plugin version, but you should do it in the pluginManagement section instead. See this post for how and why.
2. Notice the assembly plugin configuration has an execution, while the jar plugin does not. This is because the jar plugin will run automatically based on the packaging, which is assumed to be “jar” in this example. The assembly plugin needs an execution to “bind” it to the lifecycle and here we tell it which goal to run and which phase to run in.
3. Notice also that the jar plugin is configured in pluginManagement. This is my personal best practice and I explain why here.

See more Maven How-Tos and Best Practices here.

With it’s default behavior, Maven runs a plugin invocation for each project in a multi-module build. For plugins that operate on a single project at a time, this is what the author wants.

Some plugins are what we call “aggregators” which means they actually do want all the information about the full multi-module build before execution. These plugins, when run on a tree of projects cause Maven to resolve all the children before calling the plugin’s execute() method. In this mode a plugin executes just once, but effectively on the whole tree at once. (as a side note, you never want to bind an aggregator goal in your pom as this would cause the plugin to run an n! recursive build since the lifecycle would step into each child and execute the aggregator…which would cause Maven to reresolve all the children, etc)

Sometimes neither of those behaviors are what you want. If I want a plugin to run only once in my build, I can do that by only binding it once in a pom. But what if you want it to run once regardless of if I start my build at the root, or somewhere down in a module? An example of where this is handy is the maven-enforcer-plugin… if you’re checking environmental constraints like jdk, os, maven version, it’s pretty much guaranteed that this can’t change between the root and when the next module is built.

This has most recently cropped up as a use case in the maven-assembly-plugin. We want to configure the plugin to produce a source archive during releases of the entire tree. Since the root project would contain the code below that point, we don’t need to also archive the source for each sub-module separately. We want to be able to configure this at our “Maven” or “Apache” pom (the moral equivalent of a “Corporate” pom) and have it simply work regardless of where a build is launched from.

It turns out that it is fairly easy for a plugin to programatically detect when it is building the project at the execution root (that is where mvn was launched). The code looks like this:

57

        boolean result = mavenSession.getExecutionRootDirectory().equalsIgnoreCase(basedir.toString());

A full mojo to implement this would look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

/**
* @goal skipper
* @execute phase="validate"
**/
public class SkipperMojo extends AbstractMojo
{
    /**
     * Base directory of the project.
     *
     * @parameter default-value="${basedir}"
     * @required
     * @readonly
     */
    private File basedir;
 
    /**
     * This will cause the assembly to run only at the top of a given module tree. That is, run in the project
     * contained in the same folder where the mvn execution was launched.
     * @parameter expression="${runOnlyAtExecutionRoot}" default-value="false"
     * @since 2.2-beta-4
     */
    private boolean runOnlyAtExecutionRoot;
 
    public void execute()
        throws MojoExecutionException, MojoFailureException
    {
 
        //run only at the execution root.
        if (runOnlyAtExecutionRoot && !isThisTheExecutionRoot())
        {
            getLog().info( "Skipping the assembly in this project because it's not the Execution Root" );
        }
        else
        {
            getLog().info("Doing something usefull");
        }
   }
    /**
     * Returns true if the current project is located at the Execution Root Directory (where mvn was launched)
     * @return
     */
    protected boolean isThisTheExecutionRoot()
    {
        Log log = this.getLog();
        log.debug("Root Folder:" + mavenSession.getExecutionRootDirectory());
        log.debug("Current Folder:"+ basedir );
        boolean result = mavenSession.getExecutionRootDirectory().equalsIgnoreCase(basedir.toString());
        if (result)
        {
            log.debug( "This is the execution root." );
        }
        else
        {
            log.debug( "This is NOT the execution root." );
        }
        return result;
    }
}

Anders Nawroth of the Neo4J project asked an interesting question on the neo4j-user list:

What’s the best option when deploying neo4j code examples using Maven? It’s really not of any interest to deploy the artifact itself, it’s the sources (if possible with some exclusion of resources) that we want.

Anders’ requirements: create a project which packages itself, wire the appropriate goal into the lifecycle. He’s headed in the right direction, the Maven Assembly Plugin, but he might not know about the pre-defined assembly descriptors as they are somewhat hidden on the Apache Maven site. Since other projects might have similar requirements, here’s a quick explanation of all the moving parts…

What is the Maven Assembly Plugin?

The Maven Assembly Plugin allows you to create an archive with an arbitrary structure. If you have a project which needs to produce a ZIP file with a bin/ directory an a set of shell scripts, or if you want to create an archive which contains a particular project’s bytecode and all the runtime dependencies, Maven Assembly Plugin is the place to look. To generate an archive, you’ll need to do a few things:

• Include the Maven Assembly Plugin in your project’s pom.xml file.
• Configure an assembly by referencing a built-in assembly or define your own assembly.
• (optional) configure the lifecycle to bind the assembly goal to the package phase of the lifecycle.

What is an Assembly?

The Maven Assembly Plugin produces an assembly of files and folders using an Assembly descriptor which describes the contents of a directory. You can use one of several predefined assembly descriptors which are built into the Maven Assembly plugin, or you can define your own assembly by configuring your assembly in an assembly descriptor.   An assembly descriptor is an XML file which selects files and directories to include in the final, assembled artifact.

Just what sort of “assemblies” can you create on your own with an Assembly descriptor?   Just about anything, a collection of .class files and all of your runtime dependency JARs?  Sure.  The assembly descriptor is flexible enough to describe just about anything.   If you want a full explanation of the power of Maven Assemblies, read the Assemblies Chapter of the Free Maven Book or Chapter 4 which introduces a built-in assembly descriptor.

A Project Which Assembles Itself

Back to Anders’ requirements, he wants a project that can package itself up as an example project.    He also wants this assembly to be created when he runs mvn deploy.  To do this, he can use the built-in project descriptor.   Adding the following plugin configuration to any project will configure this built-in project descriptor to create an assembly of a project itself (a self-replicating project) and the executions section will attach the “assembly:attached” goal to the package phase of the lifecycle.

  <build>
    <plugins>
      <plugin>
        <artifactId>maven-assembly-plugin</artifactId>
        <configuration>
          <descriptorRefs>
            <descriptorRef>project</descriptorRef>
          </descriptorRefs>
        </configuration>
        <executions>
          <execution>
            <id>examples</id>
            <phase>package</phase>
            <goals>
              <goal>attached</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

Go ahead, try it. Run mvn package or mvn deploy and you’ll end up with an assembly in ${basedir}/target. If you want to customize the name of the final product, use the finalName element in the build section of your POM.

The Lifecycle

My next post will likely be on the lifecycle, I’ve had a few questions from people over the past few weeks about running specific goals directly from the command-line.  It appears that many people haven’t fully grok’d the Maven Lifecycle.  Many people grew familiar with Maven 1, the way that people customized a build in Maven 1 was to string along a number of goals.   If you needed to run a specific goal, you would just craft a long command line.   In Maven 2, you should shy away from running specific goals on the command line, and you should configure executions (see above).   This is the more natural way to customize a build, think of it as hooking your own project’s customized goals to the default lifecycle.   If you find yourself running “mvn deploy assembly:assembly” often, you should take a look at the executions element in your plugin configuration.

For more information about the Maven 2 Lifecycle, read Chapter 10: Lifecycles.

Maven has two sections in the pom relating to plugin configuration: project.build.plugins and project.build.pluginManagment.plugins. These two sections are unfortunately often confused and misused. PluginManagement is similar to dependencyManagment in that it provides configuration and defaults for plugins if they are used in the build. This is where we recommend you lock down your plugin versions, but it also allows default configuration.

The regular plugins section also allows the version and default configuration to be defined, and this is where the confusion lies. It is technically valid to define the plugin version and default configuration here, but I find it easier to grok the pom when following this guideline:

• If the plugin block is not defining an execution (and thus binding maven to do something in the lifecycle), put that block in pluginManagment

This means that configuration for plugins brought in by the default lifecycle such as resources, compiler, jar, etc will almost always go in the pluginManagement section. Doing so tends to keep your regular plugins section rather small and only showing the config for plugins that are doing additional things during the lifecycle.

Following the above defined guideline will also have you locating the config for plugins that are primarily run from the command line in pluginManagment…again keeping the plugins section clean and concise.

Maven 2.0.9 introduced the ability to override a dependency used by a plugin. This is handy when you want to use a newer checkstyle, pmd, etc jar than is included by default in the plugin.

How you go about doing this actually depends on your use case because of an oversight in the Maven 4.0.0 model used by the Maven 2.0.x versions.

If you are using a plugin as a normal build plugin (as opposed to a report) then you will have it bound similar to this:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-checkstyle-plugin</artifactId>
  <version>2.1</version>
  <executions>
      <execution>
        <id>check my sources</id>
        <goals>
          <goal>check</goal>
        </goals>
        <phase>compile</phase>
      </execution>
  </executions>
</plugin>

This version of the maven-checkstyle-plugin will use checkstyle 4.1 by default. If I wanted to use version 4.4 instead, I simply add a dependency block inside my plugin block like this:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-checkstyle-plugin</artifactId>
  <version>2.1</version>
  <executions>
      <execution>
        <id>check my sources</id>
        <goals>
          <goal>check</goal>
        </goals>
        <phase>compile</phase>
      </execution>
  </executions>
  <dependencies>
     <dependency>
        <groupId>checkstyle</groupId>
        <artifactId>checkstyle</artifactId>
        <version>4.4</version>
     </dependency>
  </dependencies>
</plugin>

That was easy, right? As long as the new version you have introduced is api compatible with the version the plugin was linked against, you should be good.

Now, what about reports? Well unfortunately, the Model used in 2.0.x doesn’t allow dependencies to be specified inside the reporting block (MNG-1948)

In the process of creating the samples for this how-to, I discovered that the extensions don’t override the reporting plugin dependencies, so unfortunately there isn’t a way to override them. Stay tuned as we investigate how to deal with this.

Update: There is a way to make this happen with reports. In the example below, I removed the execution from the plugin block and added the plugin as a report. It seems that the dependency is inherited when the plugin is used in reporting. Not quite obvious, but here’s what it looks like:

<build>
   <plugins>
      <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-checkstyle-plugin</artifactId>
         <version>2.1</version>
         <dependencies>
            <dependency>
               <groupId>checkstyle</groupId>
               <artifactId>checkstyle</artifactId>
               <version>4.4</version>
            </dependency>
         </dependencies>
      </plugin>
   </plugins>
</build>
<reporting>
   <plugins>
      <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-checkstyle-plugin</artifactId>
         <version>2.1</version>
      </plugin>
   </plugins>
</reporting>

Checkstyle makes it easy to test this behavior because it writes out the checkstyle version in the results:

<?xml version="1.0" encoding="UTF-8"?>
<checkstyle version="4.4">

Maven 2.0.9 was released today. I previously blogged about the changes to the process that will hopefully lead to more stable releases in the future. Today I want to talk about some important changes in the release itself that improve the user experience a bit.

Probably the biggest and most anticipated change is the shift towards specifying default versions for the core set of plugins. Before I go further, lets have a background lesson on how Maven handles the plugins and why this was a pain point for some users. Unlike dependencies, Maven does not require a version of plugins to be specified. Ostensibly, this is because many plugins are introduced to the build lifecycle via one of the supported packaging types (jar,war,ear,etc). It’s not immediately obvious to a user exactly which plugins will be used and which versions they want to use. Requiring a version declaration in the pom for all plugins would immediately fail even the simplest of poms and is definately not newbie friendly.

If Maven encounters a plugin with no version declaration, regardless if introduced by the user or the packaging type, it will query the repository metadata to find the LATEST version. LATEST and RELEASE are keywords that have special meaning but are recorded in the maven.metadata.xml. The maven-dependency-plugin’s metdata is shown below:

 <metadata>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>2.0-alpha-1-SNAPSHOT</version>
    <versioning>
      <latest>2.1-SNAPSHOT</latest>
      <release>2.0</release>
      <versions>
        <version>2.0-alpha-1-SNAPSHOT</version>
        <version>2.0-alpha-2-SNAPSHOT</version>
        <version>2.0-alpha-3-SNAPSHOT</version>
        <version>2.0-alpha-4-SNAPSHOT</version>
        <version>2.0-alpha-5-SNAPSHOT</version>
        <version>2.0-SNAPSHOT</version>
        <version>2.0-alpha-1</version>
        <version>2.0-alpha-2</version>
        <version>2.0-alpha-3</version>
        <version>2.0-alpha-4</version>
        <version>2.0</version>
        <version>2.1-SNAPSHOT</version>
      </versions>
      <lastUpdated>20080302232758</lastUpdated>
    </versioning>
  </metadata>

Note that this metadata is actually the metadata merged by Nexus from both the release and snapshots repositories that house the dependency plugin. Notice that LATEST is 2.1-SNAPSHOT, while RELEASE is 2.0. This is one reason why we recommend not combining snapshots and releases in the same repository. It is also why if you are add the apache or codehaus snapshot repositories to your settings you can get some odd behavior.

Every time a new release is pushed out, this metadata gets updated. Maven by default won’t look for a new LATEST if you already have a version of the plugin in your repository. That means a few things. First, it means that if we release a plugin you might not immediately pull it down. Second, it means that new members of your team are more likely to get new versions of the plugin than older ones…creating team platform inconsistencies. It is also why we sometimes tell you to try -U to look for new plugins.

So how do I avoid being subject to new plugin releases at inopportune times or having inconsistent results across a team?

It’s pretty easy actually: specify a version in your pom. If you have a large project or group of projects, this is not very scalable. The way to handle this is parallel to dependencies: define the version in build.pluginManagment and then omit the version in the build.plugins section.

During our Maven training classes, we recommend creating a single corporate pom from which all your projects inherit. You may have individual business unit poms and team poms, but the point is you inherit up to a central pom where you can control certain things, particularly plugin versions.

Ok, now I know how to control my plugin versions, how do I know which versions I want?

Good question and there isn’t a great answer right now. The best way would be to use the new enforcer plugin to require all plugins are locked down. If it finds a plugin in use that isn’t locked down, it will tell you and it will tell you which plugin you are currently using. Unfortunately this is only available in the latest snapshot…but I promise to get it released shortly.

In the meantime, the best way to go is to look in your local repository at org.apache.maven.plugins and org.codehaus.mojo. Record the plugins you find there and use the highest release. If you want to see what the most recent version in central is, then search or browse for your plugin on our public Nexus instance and look for the highest non snapshot version.

So how does 2.0.9 fit into all of this?

Many users are not locking down their plugin versions for many different reasons. Because of this it is unfortunately common to see people having build issues pretty quickly after a plugin release.

For a long time, the Maven team resisted locking down the plugins in lieu of a better solution and user education. One of the prime reasons was as I mentioned earlier, forcing plugins to have a declared version was not newbie friendly. Unfortunately the better solution has yet to materialize and the users continued to have trouble.

Recognizing that we had to do something to ease the pain, we came up with a fairly simple solution: provide default versions in the pluginManagement section of the superpom. We are, in effect, doing exactly what we teach in the classes. The benefit of doing this is that now core plugin versions will not “randomly” change on you unless you change your Maven version. Because local poms override inherited poms, this has no impact on builds that are already locking down their plugin versions.

What’s the fine print?

There are a few gotchas.

• It’s not practical for us to track all the plugins in the Maven universe. What we have locked in the super pom are all plugins injected by the default lifecycles and a couple other common ones like assembly and dependency. Everything else is still subject to LATEST updates.
• You won’t get plugin updates for these core plugins at all until you upgrade Maven.
• Your build may not be reproducible in the future if you’re using a new version of Maven because the plugins will likely be different.
• If you upgrade to a new version of Maven and your build breaks, it won’t be immediately apparent if the core caused the issue, or if it’s one of the plugins that changed

For these reasons and more, we highly recommend that you start taking control of your plugin versions and locking them down. This way you can try out one new plugin at a time, adjust if needed and then lock it. Once the 1.0 version of the enforcer plugin gets released this will be much easier to deal with. I’m also planning to share the code with the help plugin to make something like help:current-plugins.

There are several other exciting changes in 2.0.9 that are highlighted in the release notes.

In the meantime, the plan for 2.0.10 is laid out here and we are moving along, focused on killing regressions from older versions and fixing the popular issues so please vote on your favorite (or resented) issues.