...
I think it is worthwhile defining the lifecycle by the packaging, so the phases are fixed, but their mapping to
goals are defined as configuration inside the artifact type handler. This For example, this allows a plugin artifact to add a bind the plugin:descriptor
goal automatically. It also allows a packaging of pom to not register any of the goals other than install/deploy.
The alternative is to always register them, disregarding the type, and use the type as a mojo execution guard - but
I think this might be less clean in this particular case.
Lifecycle alterations
The proposed changes are to allow a parallel lifecycle to execute for certain goals, gathering the end results but not mixing in the lifecycle elements and changed parameters with the existing lifecycle.
So far, we have the @executePhase tag which does this - eg in idea:idea to execute generate-sources first.
Here, we look at a few use cases and how they might work with the proposed changes.
Use cases:
- plexus application use case
- idea:idea running generate-sources (defined by the mojo)
- assembly:assembly running package (defined by the project)
- clover running tests
- jcoverage, modifying class files
- reports running tests, etc
...