On Fri 15 Nov 2019 at 09:18, Robert Scholte <rfscho...@apache.org> wrote:
> On 13-11-2019 21:46:04, Stephen Connolly <stephen.alan.conno...@gmail.com> > 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
