Page History

...

This page will take a stab on announcing breaking changes with latest upcoming Maven versions, and to discuss "best practices" for building Maven Plugins. This page assumes that reader know the general "best practices" for Java Projects (as Maven Plugins are basically Java projects).

Incoming Breaking Changes

Maven Project resources are limited we cannot cover "backward compatilibty" across two major versions. Hence, Maven 2 support is about to be removed. Below is the summary of breaking changes, that will happen in upcoming Maven 3.9.0 and 4.0.0:

•  MNG-6965 The org.codehaus.plexus:plexus-utils artifact is not anymore "auto injected" (auto provided) to plugins classpath. Maven 2 did provide this dependency from Maven Core automatically to plugins and extensions, then Maven 3.0.0-alpha-3 added this feature to ease plugins transition MNG-3819. This is not the case anymore. Plugin developers have to prepare for this change. Backward compatible change is really simple: just declare dependency on plexus-utils in compile scope, if your plugin does use classes from it, but does not have it declared (or have it in provided scope).
• If you depend on org.apache.maven:maven-compat (the Maven2 compatibility layer), it's really time to look for alternatives. Note: this dependency in test scope is "acceptable" and actually required by some testing frameworks (see below). This module is not removed in 3.9.0, nor in first releases of 4.0.x, but as part of Maven 2 backward compatibility layer, is to be removed somewhere in future.

Incoming Notable Changes

Maven 4.0.0 brings some new things in the play:

• A brand new immutable Maven API. Finally Maven gets a proper API, that solves two things: developers of plugins can unlesh all the Maven power without jumping hoops and loops, and for us (Maven developers) even better: the Maven implementation finally gets hidden, we can freely hack away. The idea is that the new Maven API becomes the "only touch point" between Plugins and Maven, so Maven Core should not be hindered to evolve with preserving binary compatibility of it's internals (as they will be not accessible, sealed off). Maven API will be available starting with 4.0.0 release of Maven, and we will offer "transition time" for plugins as first Maven 4.0.x (undefined yet for how long) will support both, "old way written Maven Plugins" (as today) and Maven API. But, once you convert to Maven API, your plugin will have a prerequisite of Maven 4+.
• Default Maven Transport changes from legacy Wagon to more modern Resolver HTTP "native" transport. For plugin developers this should not be a huge change, as Wagon is still exposed via (deprecated Maven 3.x APIs), while new Maven 4 Transport API was introduced, that is intentionally simplistic, to cover most common (simple) cases. Still, if plugin needs something more, that cannot me achieved using this Transport API (nor using M4 Resolver API), it should roll it's own transport.

Minimal Set Of Best Practices

Maven Plugins are meant to be invoked by and run within Maven. Hence, one can draw a parallel between them and, for example, Java Servlets, where Servlet Container "provides" some dependencies to implementations. In this aspect: Maven is also a Container, container for Maven Plugins. Maven provides to plugins the "Maven API" classloader as parent, but to build a plugin, you still need to declare some depedencies.

...

Then you can enlist your other (non-Maven) dependencies as well.

Testing Maven Plugins

Testing Maven Plugins is not trivial thing, given they are Maven Components, but not plain Eclipse Sisu or Codehaus Plexus components, but rather the plugin descriptor needs to be "translated" and installed into (any of two) container, plus the existing components in Maven Plugin JAR, if any. Hence, simplest is to use some existing frameworks for testing Maven Plugins.

...