I have to admit that when trying to figure out from a Maven perspective it felt like post-X should be called with pre-X too, but that opinion has changed. Why would anybody call pre-X? I'd say to bring the system ready to do custom X stuff, so it should stop here executing any other phases. However, when pre-X fails, I can imagine that post-X should be called too, as Maven wasn't able to bring the system in the right state.
The problem lies in that Maven restarts the lifecycle. If only we could do something like - run up until pre-X (pause the lifecycle execution) - do your custom stuff - finish with the post-X Thinking about some kind of pause... This way at least we won't break the lifecycle and leave it clean. On 15-11-2019 11:07:23, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: On Fri 15 Nov 2019 at 09:18, Robert Scholte wrote: > On 13-11-2019 21:46:04, Stephen Connolly > wrote: > On Wed 13 Nov 2019 at 19:29, Robert Scholte wrote: > > > The name of the branch contains MNG-5668, but it contains much more. > > I'd likely lead to comments like "great", without being explicit saying > > which part(s). > > I am aware there's all proposals touch the same code, but can be released > > isolated from each other. > > e.g. if the enums-value are changed to "pre-" and "post-" it should work > > for the existing phases, which means we could already use it quite soon > > (still need to test it myself, though) > > I also want to provide a counter proposal, but that takes time and for me > > there are other issues more important. > > > How would you handle the use case that we’ve already had reported: > > As a user I want to test my integration tests in my IDE by running `mvn > integration-test` so that the test environment is not torn down and I can > debug and rerun the tests until I’m ready > > Robert Scholte: > I'd say if they want to set up there environment for the integration > tests, they'd be running pre-integration-test. > Next select in the IDE the test to execute. I don't see an issue here. > Calling pre-integration-test implies NOT running post-integration-test. I disagree. I think if you run the pre- phase then you should have the post- also run I think we could have a differential failure mode in the pre-phases though. Iow a pre- phase failure returns a different exit code than the actual phase itself > > > Every time I explain people about how Maven works with phases, they are > amazed it doesn't run the post-phase. I doubt we'll see issues if we switch > to expected behavior. > > Based on the different views, I hope to see more involvement of PMC > members, because this will be a turning point that probable cannot be > undone. > > > With the new phases, the existing pom will still work, and some user opting > into after:integration-test knows what they are getting > > > > > > My biggest fear is that this will result in an All-Or-Nothing, and I like > > to prevent that. If the try-finally part works as expected we can extract > > that part and prepare for one of the next Maven releases. > > > I’d like to understand your fear better. I’ve been playing with the PoC a > bit, and TBH it just feels right. > > For sure I’d prefer a schema change to encoding in a string, but I’m also > inclined towards string encoded dependency GAVs for 5.x so that wouldn’t be > the worst if we went that way. > > With pom rewriting, I think we could do a 4.1.0 model version that moved > the execution point and priority to attributes, by writing as a 4.0.0 with > the string encoded form... iow rewriting in 4.x allows us to tidy up the > schema as long as it has a 1:1 mapping to a 4.0.0 modelVersion that gets > deployed. > > > > > > Robert > > > > > > > > > > > > On 12-11-2019 10:25:42, Stephen Connolly > > wrote: > > On Tue 12 Nov 2019 at 07:34, Robert Scholte wrote: > > > > > 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:) > > > > > > All detailed in the proposal on the wiki: > > https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases > > > > Reducing phases would be a big change and not before 4.x at least (maybe > > 5.x more realistically... at least we’d need to deprecate the phases for > a > > good while before removing any) > > > > > > > > > > I would like see separate branches for all of them, as they all have > > their > > > own discussion. > > > > > > The whole point of a PoC is the get feedback. I don’t see utility in > > separate branches as they are all touching the same code. > > > > Once we get feedback we can decide where we want to go from there. > > > > > > > > > > Robert > > > On 11-11-2019 20:31:44, Stephen Connolly > > > 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 > > > > > > > > > -- > > Sent from my phone > > > -- > Sent from my phone > -- Sent from my phone
