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
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>localdomain</groupId>
<artifactId>foo</artifactId>
<version>1.0-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>1</id>
<phase>before:integration-test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo message="hi from execution 1"/>
</tasks>
</configuration>
</execution>
<execution>
<id>2</id>
<phase>before:integration-test[1000]</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo message="execution 2 happens before 1
even though later in the pom"/>
</tasks>
</configuration>
</execution>
<execution>
<id>3</id>
<phase>after:integration-test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo message="execution 3 always executes
if we start the integration-test phase"/>
</tasks>
</configuration>
</execution>
<execution>
<id>4</id>
<phase>integration-test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<fail/><!-- time to fail the build-->
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
On Sun, 27 Oct 2019 at 10:55, Robert Scholte <rfscho...@apache.org> 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 <phase>-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 <stephen.alan.conno...@gmail.com>
> 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
>
