Well you might have asked the question, but the answers are for everyone to learn from.
I don't have trouble with execution order since doing 2 things. One is implementing the sortpom maven plugin. The other is configuring all plugin executions in pluginManagement as early as possible, but with phase = none. Then children activate plugin executions by simply setting the phase. I even don't use the default resources plugin execution. With a setup like this, if I had your profile interpolation issue, I'd try turn on the offending plugins in my top-level pom (since the plugin is then invoked every time, it becomes deterministic. But since the execution phase isn't set, it doesn't do anything. Then in the event the profile is activated, it doesn't change the fact of whether the plugin is invoked or not) Cheers, Delany On Sat, 8 May 2021 at 17:03, Alexander Kriegisch <[email protected]> wrote: > Nooo! I don't need extra phases, nor do I have any desire to create > custom lifecycles, even though I know this is possible. My point was: If > we cannot rely on a specific order when executing plugins and executions > within them in the same phase, the logical consequence for deterministic > behaviour would be one phase per plugin or execution. That would be > overkill to the 5th power. My question was how to achieve reliably > predictable ordering. That question is yet to be answered. > > I am afraid, just like with the last question I asked here (about the > dependency-reduced POM ), in the end I am not going to get a conclusive > answer and the thread will just trickle out. Or with my PR for Maven > Shade Plugin which did not get a single reaction, even though it fixes > an old problem, adding new functionality. But maybe I just need to be > more patient. :-) > > To everyone who already replied to me, thank you so much for helping me > understand some things better. > -- > Alexander Kriegisch > https://scrum-master.de > > > Lasse Lindqvist schrieb am 08.05.2021 18:35 (GMT +07:00): > > > Hi. In case you really need custom phases, it is possible to add them. > See > > https://github.com/raydac/mvn-finisher for an example for adding new > > phases. But I would say this is the last resort in case no other > solutions > > work for you. > > > > la 8. toukok. 2021 klo 10.40 Alexander Kriegisch ( > [email protected]) > > kirjoitti: > > > >> >> 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 > >> > >> IMO, that is a very unfortunate "design choice", complex situation or or > >> not. Because if you want to order plugins, in theory you would need a > >> separate phase for each. But phases in a lifecycle are limited. > >> > >> > - 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? > >> > >> It is not so much about what I prefer. It is about it being > >> deterministic with clear, documented, release-stable rules. I could > >> adjust my POM to whatever those hypothetical rules would say. > >> > >> > - 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 > >> > >> Actually, I want both, to determine the order of executions within the > >> same phase within the same plugin as well as the execution order of > >> sifferent plugins in the same phase. But my described use case here was > >> the latter, i.e. the problem really is about two different plugins. > >> > >> To make a long story short: My use case is a valid one, and many users > >> face the same situation. What does the Maven team recommend? How is this > >> to be handled in a canonical way? Just saying "you cannot rely on it" > >> does not solve the problem. > >> > >> > >> > >> > 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] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
