[ 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 {{Node}}: * 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 was: The idea would be to redefine a maven lifecycle as being defined by: {{{}Lifecycle{}}}: * id: unique identifier * set of Phase {{{}Phase{}}}: * name (or id) * optional mojo execution (with the same id ?) * list of predecessors (name of phases it depends on) for the current project and for other projects * list of successors for the current project and for other projects 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 > 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 > {{Node}}: > * 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 -- This message was sent by Atlassian Jira (v8.20.10#820010)