I've often desired some additional logic here that is related and may side-step this:
Think about how pluginManagement allows you to define something that only applies once a child pom "mentions" the plugin. Apply the same logic to an execution, where you could define one ore more default executions but then selectively inherit/activate just the one you want in a child pom. This has happened to me mostly in the past with some of the more generic plugins like antrun, where you want to have two mostly mutually exclusive sets of default executions and a given child activates one or the other (potentially both) based on "mentioning the execution" That said, I feel like the plugin level inherited value should simply define the default, where the executions could override. Null in the execution means use the plugin level setting (where null = true) inherited = (execution.inherited !=null) ? execution.inherited : plugin.inherited On Thu, Apr 1, 2010 at 10:51 AM, Benjamin Bentmann <[email protected]> wrote: > Hi, > > I would appreciate some comments on the above issue MNG-2103 where users > requested that plugin.execution.inherited generally overrides > plugin.inherited. > > Considering the three possible values for the inherited field (true != false > != null), we currently determine the inheritance of an execution based on > > inherited = (plugin.execution.inherited != false) && (plugin.inherited != > false) > > i.e. explicitly setting inherited=false at either the plugin or the > execution level stops the inheritance. > > In contrast, the issue requests the logic > > inherited = (plugin.execution.inherited == true) || > (plugin.execution.inherited == null && plugin.inherited != false) > > i.e. the plugin level setting provides a default that can be overriden at > execution level. This mode would also raise the question what happens to > plugin-level configuration if plugin.inherited=false but > plugin.execution.inherited=true. > > This would be a significant change in behavior that could negatively affect > existing builds. The one scenario I could think of is an inheritance > hierarchy like > > A (plugin.inherited=true) > +- B (plugin.inherited=false) > +- C (no more inheritance here) > > i.e. the parent POM B can currently disable any plugin execution inheritance > to its children by just setting plugin.inherited=false, regardless what the > plugin.execution.inherited field of any execution says. The changed logic > would require POM B to override the inherited flag of each execution that > has inherited=true. > > So do we want to change the existing behavior or not? > > > Benjamin > > --------------------------------------------------------------------- > 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]
