...

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.

...