> Child modules can add configuration to mojo executions configured in > parent pom. This isn't pretty, but works. >
That's not what I had in mind. I was talking about one plugin binding in the parent pom and then a different plugin binding in the child, which we want to be after the one in the parent. Then only having "dependsOn" wouldn't work in a case where we can't update the parent. > And, to be clear, I am not saying we shouldn't implement before/after > configuration, I think it will be convenient to have both. All I am > saying only one is truly required. Not in the case I describe (I think). > > -- > Regards, > Igor > > On 2014-06-12, 2:23, Anders Hammar wrote: > >> >>> Having said that, I think having both "before" and "after" attributes >>> will make configuration easier in some cases, but I still think all >>> ordering can be expressed just with dependsOf (which is the same as >>> "after"). >>> >> >> >> Let's say you're not in control of the pom where the plugin binding is >> declared, which you want to add a binding before. Then it is not possible >> to add the "dependsOn". One scenario would be a parent pom you're >> inheriting from. >> >> /Anders >> >> >> >>> -- >>> Regards, >>> Igor >>> >>> >>> >>> >>> On 2014-06-11, 15:44, Robert Scholte wrote: >>> >>> The "dependsOn" would only help if this execution should be done *after* >>>> another execution. However, I think we also need a solution for the >>>> *before* one, unless we say: just manage this by ordering your plugins. >>>> Keep in mind: what to do if executions are defined in the parent and you >>>> want to execute your plugin before and/or after these inherited >>>> executions? >>>> >>>> Thanks, >>>> Robert >>>> >>>> Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko >>>> <i...@ifedorenko.com>: >>>> >>>> Misconfigured execution order should be reported as build failer. >>>> >>>>> >>>>> I don't see how profiles make this problem more complicated. It maybe >>>>> little tedious to configure, but I believe it is always possible to add >>>>> dependsOn attribute to execution defined elsewhere. So in your example, >>>>> the release profile will need to define execution with id of the "final >>>>> step" and add dependsOf="id-of-sign-step". >>>>> >>>>> -- >>>>> Regards, >>>>> Igor >>>>> >>>>> On 2014-06-11, 15:17, Jörg Schaible wrote: >>>>> >>>>> Hi Igor, >>>>>> >>>>>> Igor Fedorenko wrote: >>>>>> >>>>>> More I think about it, less I like the idea of explicit order >>>>>> values. I >>>>>> >>>>>>> think this will be rather inconvenient to setup and error prone to >>>>>>> maintain. >>>>>>> >>>>>>> Initial setup will require some tooling to see executions in a >>>>>>> particular case with their default ordering values. Not the end of >>>>>>> the >>>>>>> world, but somebody will have to implement the tooling and the users >>>>>>> will know how to find it. >>>>>>> >>>>>>> More problematic will be ongoing changes to the project itself >>>>>>> and its parents. When I need to add/remove executions in a parent, I >>>>>>> will have to review all projects that inherit from it to ensure >>>>>>> order is >>>>>>> still correct. I work on a monster codebase with 600+ modules now, I >>>>>>> just don't see how this is workable. >>>>>>> >>>>>>> If executions are enabled through a profile, especially rarely >>>>>>> activated >>>>>>> profile, configuring expected order becomes really cumbersome. >>>>>>> Think of -Prelease profile, that adds gpg mojo to package phase... >>>>>>> good luck troubleshooting why signed jars do not match their gpg >>>>>>> signatures during the release. >>>>>>> >>>>>>> I think we need to find a way to make before/after hints work. I >>>>>>> don't >>>>>>> have a proposal yet, but I wonder, is this not the same problem as >>>>>>> ordering modules in the reactor? When there are no dependencies, >>>>>>> modules >>>>>>> are built in their specified order, but the order changes when there >>>>>>> are >>>>>>> dependencies. >>>>>>> >>>>>>> >>>>>> please have a look at the latest comments on MNG-3522, because adding >>>>>> executions in a profile causes some edge cases, which should be >>>>>> defined in >>>>>> advance. >>>>>> >>>>>> Regards, >>>>>> Jörg >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>>> >>>>>> ------------------------------------------------------------ >>>>> --------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> >>>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
