> > 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 > >
