On 10 September 2011 19:35, Anders Hammar <[email protected]> wrote: >> So what you appear to be saying is that the pluginManagement execution >> configuration *is* inherited? > > Yes, as pluginMgmt. > >> But that you might not want to provide the execution config there if >> it is not generic. > > If you mean generic for all children, then yes.
Yes. >> 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. > > Yes. I believe Brian explained this very well. Yes. >> 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 > > Yes, I guess. > But, I wouldn't make it more complicated than it is. If you're adding > the binding in the parent, then I would define everything (possibly > except the version) in parent/build/plugins. No need to split it > between pluginMgmt and plugin. It would just make the pom harder to > read. Now you're confusing me again. You say - below - that CLI (goal) invocations ignore the build/plugins settings. If so, then surely it's better to define everything in pluginMgmt, and just leave the build/plugins section to reference the plugin? In which case both goal and phase invocations share the settings. Otherwise CLI(goal) invocations might not be fully configured. >> The pluginManagement settings will I assume apply to all CLI (i.e. >> goal) invocations. > > Yes, if you add the config on the plugin level and not on a specific > execution. > >> This is presumably because individual goal invocation is not part of a >> phase and so ignores what is in build/plugins > > Right, and this has tricked a lot of new Maven users. > > /Anders > >> >>> 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] >> >> > > --------------------------------------------------------------------- > 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]
