Thanks for your reply Jason. So it seems there are some possibilities for this ticket: either interpreting the <id> to infer order (the patch) or stuffing this into an attribute (per Igor). Regarding the latter, the attribute route is clearly to avoid adding a new POM element, but aren't both a bit "hackish"? The desired solution, I think, would be to make this a POM element, but past discussions inform me that's clearly off the table.
Cheers, Paul On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl <ja...@takari.io> wrote: > I'm opposed to random creation of a DAG for executions across all the > phases. This just creates a giant mess. That said _within_ a given phase if > there was a topological sorting of executions where one execution can state > that it depends on another I think is reasonable. Definitive ordering > within a phase, I think, is useful. > > On Jun 4, 2014, at 10:22 AM, Paul Benedict <pbened...@apache.org> wrote: > > > I find that solution interesting because, in a way, it kind of returns us > > to the days of Maven 1.x where you can run things pre/post goal. I am > > pretty sure Jason wanted to get rid of that perspective with this 2.x > > design, but maybe things are coming full circle? > > > > > > Cheers, > > Paul > > > > > > On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko <i...@ifedorenko.com> > wrote: > > > >> Yes, I was also thinking before/after as a way to solve this. We can > >> probably use xml attributes without breaking compat with artifact > >> consumers, so I think this can be done in Maven 3.x. > >> > >> -- > >> Regards, > >> Igor > >> > >> > >> On 2014-06-04, 10:09, Robert Scholte wrote: > >> > >>> Hi Paul, > >>> > >>> that's my understanding as well. > >>> But even in a single pom you can have issues. > >>> Consider 2 plugins, with both 2 goals and you want to run it like > >>> > >>> (phase=pre-integration-test) > >>> pluginA:preSomething > >>> pluginB:preStuff > >>> > >>> (phase=post-integration-test) > >>> pluginB:postStuff > >>> pluginA:postSomething > >>> > >>> Since plugins should be unique within the build-section, it's not > >>> possible to have a clean solution for this. > >>> > >>> Instead of the step-X solution of MNG-4727 I think you should be able > to > >>> run it before or after a specified goal. > >>> We could think of using a convention for the execution-id, or define a > >>> new element in the pom-5.0.0 > >>> > >>> thanks, > >>> > >>> Robert > >>> > >>> > >>> Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict > >>> <pbened...@apache.org>: > >>> > >>> Anyone have thoughts on this ticket? There is a submitted patch, as the > >>>> last comment says -- it's part of another ticket that was marked as > >>>> duplicate. > >>>> > >>>> Though, I am a bit confused. I thought plugin execution was already > >>>> defined > >>>> by the sequential order listed in the POM. Am I incorrect? If so, I > still > >>>> don't know if that's "good enough" when using POM inheritance. > >>>> > >>>> Cheers, > >>>> Paul > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> 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 > >> > >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > A language that doesn’t affect the way you think about programming is not > worth knowing. > > -- Alan Perlis > > > > > > > > > >
