Environment

The example is based on a big project with multiple modules, supporting multiple environments (DB, AS, OS, ...), with strong constraints on the DTAP (Development, Test, Acceptance, Production) process and separation.

We found out that having one plugin declared in the parent POM of the project simplify a lot Maven management.

One Plugin Diagram

Issues to solve

Maven Plugins versions

For deployment (version management) purposes inside a big project, one plugin POM controls all the other plugins versions. Without it, build are not reproducible (new RELEASE version of any plugin on ibiblio), and plugin dependency graph unmanageable (hard to use exclusion and scope inside pluginManagment and does not work for report plugins). it is easier to have only one plugin distributed and configured for all the modules. This plugin will override the lifecycles needed for the different output (jar, war, ear, so, exe, install shield, RPM, ...), and will define all the third party Maven plugins dependencies.

Inter plugin configuration

With multiple plugins you always end up copy/pasting configuration parameters in the POM files. This is due to the isolation between plugins in plexus (should be solved in Maven 2.1).

But even with 2.1, some repetition in plugin configuration are due to default build behavior for the project (artifact renaming, filter based on naming convention, ...) more than just inter plugin issue.

Life Cycles

One very strong feature of Maven is the lifecycle configuration. But this is done in a components.xml file that need to be part of a plugin jar. So, few project are actually using this feature fully. What happens is that some plugin executions are added in the plugin configuration of the POM files, but it gets very quickly out-of-hand, unmaneageable and sometimes dead-end due to POM inheritance.

Futhermore, the modules of the project can be classified with your own terminology like:

And plugin configuration gets a lot easier if this info is availiable as if/else in configuration.

Solutions

Maven Plugins versions

With jade plugins the 3rd parties dependencies are not Maven2 plugin dependencies (with pluginManagement and plugin configuration), but plain java classpath dependency.

Now, the plugin will inherit all the Mojos and plexus components directly at the Java level, and it is possible to play with versionManagement, scope and exclusion with the standard Maven dependency configuration.

Inter plugin configuration

Since there is only one plugin, configuring it, means configuring all the plugins used. The issue that need to be watch is the usage of the same named parameter accros plugins. That's why we created common jar for jade-plugins, and the ability to override Mojo Parameters at the lowest level of the Project Mojos.

This final mojo don't have usually to overwrite the execute() method but just play with configuration in Java. So logical setup of default with if/else is natural and easy.

Life Cycles

With only one plugin and one list of Mojos it is not a burden anymore to overwrite the life cycle manager of Maven. Now that the project has it's own packaging and types, the java code inside the lowest level project Mojos can use the packaging and type information to setup the plugins correctly.