looking at its code, it seems it uses LifecycleExecutor [1] I don't know implementation details, if it has edge cases, but I suppose this will bring the same result as what Maven core will execute
Regards, Hervé [1] https://maven.apache.org/ref/3.8.1/maven-core/apidocs/org/apache/maven/lifecycle/LifecycleExecutor.html Le lundi 10 mai 2021, 11:14:12 CEST Nick Stolwijk a écrit : > Hervé, > > > What you can also do is look at "mvn help:effective-pom -Dverbose" also > > to see > > > the result without executing > > Do you know if the order that shows with `mvn > fr.jcgay.maven.plugins:buildplan-maven-plugin:list`[1] is also the > guaranteed* execution order? > > * guaranteed for that Maven version and activated profiles > > [1] https://github.com/jcgay/buildplan-maven-plugin > > With regards, > > Nick Stolwijk > > ~~~ Try to leave this world a little better than you found it and, when > your turn comes to die, you can die happy in feeling that at any rate you > have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > > On Fri, May 7, 2021 at 7:56 AM Hervé BOUTEMY <[email protected]> wrote: > > > Can anybody enlighten me on what is happening here and if this behaviour > > > is documented anywhere? Or is this just the "read the freakin' source > > > code, pal" kind of detail? > > > > order in the same phase is not expected to be guaranteed: that's a design > > choice (even if "choice" is not the best term IMHO: see below). > > Then there can't be any formal documentation: it's just what it is on each > > Maven release (and maybe has changed over time). > > see https://issues.apache.org/jira/browse/MNG-5987 > > > > On design "choice": > > I worked on it in the past to see if we could change that "choice", and > > it's > > more complex than what people think: > > - impact of profile injection, and if you want to control order, key > > question: > > in your case, do you prefer injecting profile-defined plugins before or > > after? > > - mix of plugins/goals and executions: in fact, we talk about plugins > > order, > > but what you need is goal execution order. And de-facto, given multiple > > goals > > executions are associated to one unique plugin definition during model > > building > > (that one is a design decision), you can't influence order at goal > > execution > > level but only full plugin > > > > You can read Model Builder documentation and code if you want, this is > > where > > you'll find the details: > > https://maven.apache.org/ref/current/maven-model-builder/ > > But stability over multiple Maven version remains not guaranteed. > > > > > > > > HTH > > > > Hervé > > > > Le vendredi 7 mai 2021, 01:13:53 CEST Alexander Kriegisch a écrit : > > > I notices an unexpected thing about plugin execution order: If I have > > > several plugins running in the same phase, normally they are executed in > > > the lexical order in which they appear in the POM. But there is a case > > > in which this can change. Schematically, it looks like this: > > > > > > <profiles> > > > > > > <profile P> > > > > > > <build> > > > > > > <plugins> > > > > > > <plugin A, phase X /> > > > > > > </plugins> > > > > > > </build> > > > > > > </profile P> > > > > > > </profiles> > > > > > > <build> > > > > > > <plugins> > > > > > > <plugin B, phase X /> > > > > > > </plugins> > > > > > > </build> > > > > > > My expectation was that the execution order in phase X would be plugin > > > A, then B. This is true sometimes, depending on which build other > > > profiles are active. I mean completely unrelated profiles defined in > > > other Maven modules. In my specific case, without specifying any other > > > profiles (P is auto-activated bases on non-existence of a file), the > > > order was B, A. If I manually activated any other profile or > > > de-activated a profile which otherwise would be active automatically, > > > the order changed to A, B. > > > > > > In my case, I had the option of moving plugin B to a later phase, which > > > settled the issue for me, but that is not always possible. > > > > > > Can anybody enlighten me on what is happening here and if this behaviour > > > is documented anywhere? Or is this just the "read the freakin' source > > > code, pal" kind of detail? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
