If I may compliment what Anders has said already... One of the distinctions I make between putting a plugin declaration in a parent POM versus a pluginMgmt is whether I want a plugin to be defined as a template for a given group of inherited projects or invoked for every child of that same group. The distinction is important. For instance, if I have a tree of projects starting with the parent, I might want a plugin to be configured in only one place, but only invoked on a random subset of the children. In this case, defining the *template* is the way to go (i.e. pluginMgmt), but if I want the plugin to be used everywhere (maven-source-plugin comes to mind), I define that in the plugins section of the parent project.
In the case of maven-source-plugin, if I did it as a pluginMgmt, I'd still have to *instantiate* the plugin in each build, creating four extra lines of XML in each POM (and the opportunity for someone to forget those four lines in new projects). By putting it in build/plugins, it is instantiated for *every* child build. Note there are also some pretty cool rules for defining plugins in a parent but then merging additional configuration in children. I don't remember them all, but this can be done to great effect, allowing a plugin defined in a parent to have different/additional configuration in a child. $0.02.... Brian On Sep 10, 2011, at 8:19 AM, Anders Hammar wrote: >>>>> So one use case to have move the configuration to the pluginMgmt >>>>> section would be if you want to have some config for the build AND for >>>>> when executing the plugin goal directly. >>>> I take it you mean the plugin entry in build/plugins would then just >>>> contain the groupId/artifactId. >>> >>> Yes, and the execution declaration. >> >> Sorry, what do you mean by that? >> >> Are you saying that there are parts of the pluginManagement >> definitions that are not applied to build/plugins? >> If so, is there any point in having the execution declaration in the >> pluginManagement section? > > Ok, now we're talking advanced stuff. I would only put the execution > declaration in the pluginMgmt section if it would be something that is > to be reused by several children projects. Otherwise I would put the > declaration in build/plugins/plugin in the project it belongs. > But there are exceptions to this of course. One would be if you want > to configure the default execution (the one from CLI) differently than > the one(s) bound to the lifecycle. Then you need to re-define the > default execution (which is the one from CLI) in pluginMgmt and for > that execution add the configuration you want (thus, within the > execution section, not on plugin level). > > But this is me. Others may very well have a different opinion. > > /Anders > >> >>> /Anders >>> >>>> >>>>> And some people like defining the version of plugins in the pluginMgmt >>>>> section but not in build/plugins. Then you define this in a parent and >>>>> only have one place to change when new versions are released. This is >>>>> how I do it. >>>> >>>> Yes, that is mainly how it is being used. >>>> >>>>> /Anders >>>> >>>> Thanks! >>>> >>>>> On Sat, Sep 10, 2011 at 02:14, sebb <[email protected]> wrote: >>>>>> AIUI, both build/plugins and build/pluginManagement are inherited by >>>>>> child projects, the difference being that plugiManagement entries are >>>>>> only used if the child project references the plugin in its >>>>>> build/plugins section. >>>>>> >>>>>> That being the case, if a plugin is defined in build/plugins, is there >>>>>> any point also including it in the build/pluginManagement/plugins >>>>>> section? >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
