|Maven: The Complete Reference
- 1.4. Universal Reuse through Maven Plugins
The core of Maven is pretty dumb, it doesn’t know how to do much
beyond parsing a few XML documents and keeping track of a lifecycle
and a few plugins. Maven has been designed to delegate most
responsibility to a set of Maven Plugins which can affect the Maven
Lifecycle and offer access to goals. Most of the action in Maven
happens in plugin goals which take care of things like compiling
source, packaging bytecode, publishing sites, and any other task which
need to happen in a build. The Maven you download from Apache doesn’t
know much about packaging a WAR file or running JUnit tests; most of
the intelligence of Maven is implemented in the plugins and the
plugins are retrieved from the Maven Repository. In fact, the first
time you ran something like
The Maven Surefire plugin is the plugin that is responsible for running unit tests. Somewhere between version 1.0 and the version that is in wide use today someone decided to add support for the TestNG unit testing framework in addition to the support for JUnit. This upgrade happened in a way that didn’t break backwards compatibility. If you were using the Surefire plugin to compile and execute JUnit 3 unit tests, and you upgraded to the most recent version of the Surefire plugin, your tests continued to execute without fail. But, you gained new functionality, if you want to execute unit tests in TestNG you now have that ability. You also gained the ability to run annotated JUnit 4 unit tests. You gained all of these capabilities without having to upgrade your Maven installation or install new software. Most importantly, nothing about your project had to change aside from a version number for a plugin a single Maven configuration file called the Project Object Model (POM).
It is this mechanism that affects much more than the Surefire plugin. Maven has plugins for everything from compiling Java code, to generating reports, to deploying to an application server. Maven has abstracted common build tasks into plugins which are maintained centrally and shared universally. If the state-of-the-art changes in any area of the build, if some new unit testing framework is released or if some new tool is made available, you don’t have to be the one to hack your project’s custom build system to support it. You benefit from the fact that plugins are downloaded from a remote repository and maintained centrally. This is what is meant by universal reuse through Maven plugins.