Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This page will take a stab 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 have no resources to cover "backward compatilibty" across two major versions, hence following breaking changes will happen in upcoming Maven 3.9.0 and 4.0.0:

  • 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. 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).

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

TBD