That's where the theoretical "before" attribute would be useful, right?
Cheers, Paul On Thu, Jun 12, 2014 at 3:49 PM, Anders Hammar <and...@hammar.net> wrote: > 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 > >> > >> > > >
