This is not just MNG-5668, but also contains several non-existing issues, that should be mentioned explicitly as they will have huge impact:
- support before:/after: prefix for phase-binding - introduce priority - reduce phases (this one hasn't been implemented, but seems to be the reason behind before:/after:) I would like see separate branches for all of them, as they all have their own discussion. Robert On 11-11-2019 20:31:44, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: https://github.com/apache/maven/tree/mng-5668-poc is my POC implementation for anyone interested in trying it out. Here's a pom that builds with the PoC 4.0.0 localdomain foo 1.0-SNAPSHOT maven-antrun-plugin 1 before:integration-test run 2 before:integration-test[1000] run 3 after:integration-test run 4 integration-test run On Sun, 27 Oct 2019 at 10:55, Robert Scholte wrote: > TLDR: We can do better than, but who is in control? lifecycle-owner, > plugin-owner or pom-owner? > > I think we all recognize the issues we're trying to solve, but to me this > proposal is not the right solution. > > In general there are 2 issues: > 1. provide a mechanism that makes sure some executions are called even its > matching main phase fails. > 2. provide a mechanism then ensures the order of executions. > > The problem of issue 1 is described in MNG-5668, but not the final > solution. > MNG-5668 proposes to give this power to the *lifecycle-owner*, whereas > stage 2 proposes to give the power to the *pom-owner*. > Both agree on the same thing: by default these post-phases should be > triggered even after failure of the matching main phase. This is actually > already expected behavior, so I don't expect real issues when implementing > this adjusted behavior. > To me after:integration-test is just an alias for post-integration-test, > both should work the same way. > > Issue 2 is a more common problem: controlling the order of executions. > In some cases it is pretty hard or even impossible to get the preferred > order. The latter happens when 2 goals of the same plugin must be executed > and a goal of another plugin are competing within the same phase. > > So let's first take a look at a phase: is there a clear definition? > "A phase is a step in what Maven calls a 'build lifecycle'. The build > lifecycle is an ordered sequence of phases involved in building a project". > "Lifecycle phases are intentionally vague, defined solely as > validation, testing, or deployment, and they may mean different things to > different projects." > Phases are intended to be called from the commandline, and within the pom > you define you can control what should happen before or during that phase. > > To me changing the content of the -element is a codesmell as it > becomes more than just a phase, and we start programming. Why do we need it? > In the end it is all about ensuring the order of plugin executions. > Stage3+4 proposes to give the power to the *pom-owner*, > whereas MPLUGIN-350[2] proposes to give this power to the *plugin-owner*. > IIUR Gradle does not have this issue, because their plugins are aware of > input and output. They ensure that if the output plugin X is the input of > plugin Y, than X is executed before Y. > And we should do the same. And this comes with benefits: we can decide if > executions within a project can be executed in parallel. And the pom stays > as clean as it is right now. > > In cases when there's a better ownership than the pom-owner, I would > prefer to choose that solution. I already notice how people (don't) build > up their knowledge regarding poms. The lifecycle-owner and plugin-owner > know much better what they're doing. > > thanks, > Robert > > Some food for thoughts: consider a developer that wants to run up until > pre-integration-test, because he wants to bring his system in a certain > state so he can work with IDE to do some work.Can we say that If And Only > If somebody called the pre-PHASE, there's no reason to end with the > post-PHASE? > > [1] https://issues.apache.org/jira/browse/MNG-5668 > [2] https://issues.apache.org/jira/browse/MPLUGIN-350 > On 26-10-2019 14:20:50, Stephen Connolly > wrote: > On Sat 26 Oct 2019 at 10:50, Robert Scholte wrote: > > > To avoid confusion, let's call it stages. > > > > Stage 1: Always call post-bound executions (MNG-5665[1]) > > Stage 2: before and after > > Stage 3: priorities (MNG-3522[2]) > > Stage 4: transitional lifecycle > > > I have a prototype of stages 1-3 nearly (80%) done... just have to polish > up and validate the bound executions with some tests > > > > > > For both all you need to start evaluating the value of phase. > > For now we can assume that after:clean is just another label for > > post-clean and will have exactly the same effect. > > MNG-5665 contains a proposal to change the xml, but we shouldn't do that > > (yet). Let's start with a hardcoded list of postphases (or in case a goal > > fails, see if a post-x phase exists). Stage 1 is to make it work, stage 2 > > to make it configurable. > > IIRC you cannot ask from inside a Mojo if is was called explicitly or > > because it was bound to a phase, nor can you ask for the value of this > > phase. I kind of like this, plugins shouldn't care about this. > > However, inside Maven it will become important at which phase it is to > > know if there are more executions to call OR create blocks of executions. > > Now it is just a list of executions: loop and fail fast. > > > > thanks, > > Robert > > > > [1] https://issues.apache.org/jira/browse/MNG-5665 > > [2] https://issues.apache.org/jira/browse/MNG-3522 > > On 25-10-2019 21:33:14, Stephen Connolly > > wrote: > > Robert, > > > > I would be fine splitting out into, pardon the pun, phases: > > > > Phase 1: before and after > > Phase 2: priorities > > Phase 3: transitional lifecycle > > > > Might have a phase 1.5 of before:* and after:* to catch the start of a > > lifecycle and the end of a lifecycle... > > > > On Fri 25 Oct 2019 at 20:30, Stephen Connolly > > stephen.alan.conno...@gmail.com [mailto:stephen.alan.conno...@gmail.com > ]> > > wrote: > > > > Robert, Michael, Tibor, let’s continue here (though I asked Infra and > it’s > > fine that anyone in the community can join our Slack) > > > > On Fri 25 Oct 2019 at 20:01, Stephen Connolly > > stephen.alan.conno...@gmail.com [mailto:stephen.alan.conno...@gmail.com > ]> > > wrote: > > > > https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases [ > > https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases] > > > > Thoughts? > > -- > > > > Sent from my phone > > -- > > > > Sent from my phone > > -- > > > > Sent from my phone > > -- > Sent from my phone >
