Optimal Maven Plugin configuration
A guideline to make your pom easier to understand
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:
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.
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.
Re: Optimal Maven Plugin configuration
1. Why is that so (that most plugins should be under plugin management) - what's the advantage?
2. So if I got it right, I put:
maven-clean-plugin
maven-compiler-plugin
maven-surefire-plugin
maven-install-plugin
maven-deploy-plugin
into the plugin management section, as they are part of a the regular lifecycle (even though I don't always call install or deploy?!)
And:
maven-eclipse-plugin
tomcat-maven-plugin
maven-jetty-plugin
maven-changes-plugin
maven-scm-plugin
maven-site-plugin
under the regular plugin section. Right?
But what about the maven-war-plugin?! For war files, this is also executed on a regular basis.
???
2. So if I got it right, I put:
maven-clean-plugin
maven-compiler-plugin
maven-surefire-plugin
maven-install-plugin
maven-deploy-plugin
into the plugin management section, as they are part of a the regular lifecycle (even though I don't always call install or deploy?!)
And:
maven-eclipse-plugin
tomcat-maven-plugin
maven-jetty-plugin
maven-changes-plugin
maven-scm-plugin
maven-site-plugin
under the regular plugin section. Right?
But what about the maven-war-plugin?! For war files, this is also executed on a regular basis.
???
Re: Optimal Maven Plugin configuration
1) The advantage is simply easier comprehension of the pom. Think of things in plugin Management are "providing defaults when the plugin is executed by some other mechanism...lifecycle or cli invocation." Then things in the plugin section are left for binding and adding new steps in the build process. It's a logical distinction that makes the pom easier to comprehend.
2) No, at least not unless you are binding an exectution for those plugins, which most if not all of them you won't be doing.
The rule I use is simple, if you don't use an execution block in your plugin config, put it in plugin Management.
2) No, at least not unless you are binding an exectution for those plugins, which most if not all of them you won't be doing.
The rule I use is simple, if you don't use an execution block in your plugin config, put it in plugin Management.