...
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.
...
Solution
For per-packaging lifecycles, we can do this with plexus configuration, so a PackagingHandler can specify a lifecycle as configuration, but there will be a default (which is what is there now). It is a replacement lifecycle, not an overlay.
Lifecycle execution
I think the best solution for executions was:
@execute phase="..." lifecycle="some ID"
where phase should be replaced by a name that represents whatever we call phases/goals as a combination (task?)
the lifecycle ID will be inside a /META-INF/maven/lifecycles.xml file
- we went for a separate xml file instead of java code to be able to easily visualise it
- the lifecycle in here is overlaid on the existing one when the forked goal is called
- I've decided to aggregate them in one file for simplicity rather than having per mojo files
- I don't think we can use plexus configuration here because it would require an assumption in AbstractMojo
Lifecycle Use Cases
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.
...