Re: Dynamic phases proposal

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic phases proposal

Robert Scholte-8
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 <[hidden email]> 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
> > [hidden email] [mailto:[hidden email]
> ]>
> > 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
> > [hidden email] [mailto:[hidden email]
> ]>
> > 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic phases proposal

Andreas Sewe-2
Stephen Connolly wrote:
> https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases
>
> Thoughts?

Very nice. I like this a lot. In particular, it still feels like Maven
with its well-known phases rather than like the "every project rolls
their own" approach of Ant or Gradle.

And to answer one specific question from your proposal: "Do we need a
differentiation between validate and initialize?"

I would argue that the answer is Yes; the two phases are for different
things.

To initialize I would bind something like buildnumber:create or pretty
much all of the build-helper-maven-plugin's goals. My intuition would be
that the initialize phase is where you programmatically augment the
project model.

In contrast, the validate phase is for validating your input (or
environment). Now in the common case (Java), inputs are already
validated by the compiler, but if my compile goal is xml:transform, then
it makes sense to have xml:validate bound to the validate phase, as XSL
Transforms typically don't check that diligently that their input
adheres to some expected format. (It also makes sense to bind
xml:validate bound to test or verify, too, to check the output's format.)

Just my 2 cents.

But overall, a really nice proposal.

Best wishes,

Andreas


signature.asc (849 bytes) Download Attachment