[
https://issues.apache.org/jira/browse/MNG-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8052:
---------------------------------
Description:
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
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 phases:
* {{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 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 lifecycles as a mojo execution graph
> -------------------------------------------
>
> Key: MNG-8052
> URL: https://issues.apache.org/jira/browse/MNG-8052
> Project: Maven
> Issue Type: Improvement
> Reporter: Guillaume Nodet
> Priority: Major
> Fix For: 4.0.x-candidate
>
>
> 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
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
