Sorry, my bad. I meant the binding in the child to be BEFORE the one on the parent. I can't alter the declaration in the parent in my scenario as I'm not on control of it.
/Anders (mobile) Den 12 jun 2014 22:19 skrev "Anders Hammar" <and...@hammar.net>: > > 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 >> >> >
