[
https://issues.apache.org/jira/browse/MNG-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8052:
---------------------------------
Description:
The lifecycle is now defined as a tree of phases, each phase being split with a
{{before:}} phase and a {{after:}} phase. Each phase is given a list of timing
constraints: a phase from the same lifecycle (compile must be executed after
sources), a phase in project dependencies (compile must execute after
compile-only project dependencies have reached the ready phase), or a set of
children project dependencies (to re-define aggregators, not yet implemented).
The default lifecycle is defined in the DefaultLifecycleRegistry
In addition to the before: and after: prefixes, an ordering can be defined by
appending an integer inside brackets, for example, after:integration-test[1000].
Note that there are a few changes with the Maven 3 default lifecycle: it's a
graph, so sources does not always execute after resources, nor compile after
resources. Also, unit tests and integration tests have been moved to the verify
phase which is run last inside the build phase, but not in the package phase.
The goal is to have a phase (here, package which can run all the reactor with
no tests). In order to be compatible, old phases are mapped to new ones using
aliases. The install and deploy phases now depends on package, but not verify
(and deploy does not require install). This currently has no effect when
calling mvn deploy, as the ordered list of phases is still used to compute the
build plan (see #1429).
It's missing the ability to create some scheduling constraints in the POM and
to define custom phases. All executions in a given phase such as compile or
after:sources are executed sequentially, but it would be nice to be able to
execute them in different subphases, so that they could be executed
concurrently.
was:
The idea would be to redefine a maven lifecycle as being defined by:
{{Lifecycle}}:
* id: unique identifier
* set of Phase
{{Step}}:
* optional name
* optional mojo execution
* list of predecessors and successors for the current project
* list of predecessors and successors for dependencies
* list of predecessors and successors for child modules
Default lifecycle could be defined by a set of empty steps:
* {{initialize}}
* {{{}resources{}}}: requires {{initialize}}
* {{{}sources{}}}: requires {{initialize}}
* {{{}compile{}}}: requires {{sources}}
* {{{}ready{}}}: requires {{resources, compile}}
* {{{}build{}}}: requires {{ready}}
* {{{}test{}}}: requires {{compile}}
* {{{}package{}}}: requires {{build, test}}
* {{{}integration-test{}}}: requires {{package}}
* {{{}verify{}}}: requires {{test, integration-test}}
and a set of steps bound to plugin executions
* {{m-resources-p}} required by {{resources}}
* {{m-compiler-p}} required by {{{}compile{}}}, requires {{sources}} and
dependencies at {{ready}}
* {{m-surefire-p}} required by {{test}}
* {{m-jar-p}} required by {{build}}
* {{m-failsafe-p}} required by {{integration-test}}
The {{build}} phase would be introduced to have packaged artifacts without
running any tests. The {{ready}} phase would be introduced to allow (if needed)
a small difference between being {{{}compile{}}}'d and being {{{}package{}}}'d:
simple jars can be used as dependencies when they are only compiled (using
target/classes), but if you use a custom package (for example
{{{}m-shade-p{}}}), you cannot use the compiled classes directly, but you need
the processed classes. In such a case, the {{m-shade-p}} should be required by
{{ready}} and should require {{{}m-jar-p{}}}.
This would allow:
* injecting a given plugin into an existing chain: a custom generation step is
modelled with: {{m-generator-plugin}} required by {{sources}}
* a post packaging phase would be defined with: {{my-plugin}}: requires
{{m-jar-p}}, required by {{packaging}}
* running {{mvn build}} to build all jars without running any tests
* running {{mvn -amd test}} (or something similar) would allow building the
given project with the full graph (i.e. with all dependencies at {{ready}} phase
* this immediately gives a full graph that can be built concurrently down to
the mojo level
* the ability to add predecessors onto children' modules phases allow defining
aggregate goals more easily
> Define a new lifecycle for Maven 4
> ----------------------------------
>
> Key: MNG-8052
> URL: https://issues.apache.org/jira/browse/MNG-8052
> Project: Maven
> Issue Type: New Feature
> Reporter: Guillaume Nodet
> Assignee: Guillaume Nodet
> Priority: Major
> Fix For: 4.0.0-beta-4
>
>
> The lifecycle is now defined as a tree of phases, each phase being split with
> a {{before:}} phase and a {{after:}} phase. Each phase is given a list of
> timing constraints: a phase from the same lifecycle (compile must be executed
> after sources), a phase in project dependencies (compile must execute after
> compile-only project dependencies have reached the ready phase), or a set of
> children project dependencies (to re-define aggregators, not yet implemented).
> The default lifecycle is defined in the DefaultLifecycleRegistry
> In addition to the before: and after: prefixes, an ordering can be defined by
> appending an integer inside brackets, for example,
> after:integration-test[1000].
> Note that there are a few changes with the Maven 3 default lifecycle: it's a
> graph, so sources does not always execute after resources, nor compile after
> resources. Also, unit tests and integration tests have been moved to the
> verify phase which is run last inside the build phase, but not in the package
> phase. The goal is to have a phase (here, package which can run all the
> reactor with no tests). In order to be compatible, old phases are mapped to
> new ones using aliases. The install and deploy phases now depends on package,
> but not verify (and deploy does not require install). This currently has no
> effect when calling mvn deploy, as the ordered list of phases is still used
> to compute the build plan (see #1429).
> It's missing the ability to create some scheduling constraints in the POM and
> to define custom phases. All executions in a given phase such as compile or
> after:sources are executed sequentially, but it would be nice to be able to
> execute them in different subphases, so that they could be executed
> concurrently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
