On 10 September 2011 13:19, Anders Hammar <[email protected]> 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).
So what you appear to be saying is that the pluginManagement execution configuration *is* inherited? But that you might not want to provide the execution config there if it is not generic. If I understand correctly, then supposing I want the same config (execution and all) everywhere it is used, then I can use pluginManagement in the parent to define everything. If parent and all its children use the plugin, then reference the bare plugin (no config) in the parent/build/plugins. Otherwise reference it (no config) in the child/build/plugins The pluginManagement settings will I assume apply to all CLI (i.e. goal) invocations. This is presumably because individual goal invocation is not part of a phase and so ignores what is in build/plugins > 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]
