...

1. plexus application use case
2. idea:idea running generate-sources (defined by the mojo)
3. assembly:assembly running package (defined by the project)
4. clover running tests
5. jcoverage, modifying class files
6. reports running tests, etc

...

plexus:test-runtime is like making an assembly. It would be wired in as the "executePhase " for assembly:assembly (see
below), and in turn "package" would be the executePhase for this goal. , unless it were intended to be attached like an assembly is (though the assembly plugin is probably capable of doing that on its own)

idea:idea running generate-sources

...

The project used needs to be a clone that lasts the life of the executed lifecycle and the idea:idea goal, but
goes back to normal afterwards so the effects don't hit other goals.

assembly:assembly running package (defined by the project)

This can be covered by the addition of <executePhase/> to the goal configuration, ie:

...

<plugin>
  <artifactId>maven-assembly-plugin</artifactId>
  <executePhase>package</executePhase>
  <configuration>
    ...
  </configuration>
</plugin>

Here, this would override anything specified on the mojo using @executePhase, if applicable, but otherwise would
behave identically.

Clover use case

M1 plugin:

...

Do other reports require anything additional?
junit-report:

• this executes the test goal, no change in parameters

pmd:

• standard report
• will use generated sources so needs to ensure this has been run
• might also fail based on certain threshold
• all fits

overall site:

• is this a new lifecycle, or does it run each goal on its own based on the registered reports? I believe it is the
  latter.

Random notes

• does executePhase need something that indicates "pre" in the name?
• did we decide on something like an around notation AOP style for the lifecycle?
• do we really execute a lifecycle, or just require to avoid re-executing?
  • this would avoid running test:test again
  • theoretically, test:test should be smart enough not to run again anyway
  • this could get back to the @prereq situation to some extent
  • how is it actullay run if it hasn't been already? forked lifecycle? Is this a little inconsistent?
  • common use is generated-sources which might not be fast to run over and over
  • here I would like to flatten down the lifecycle
  • still means getting back to a @requires style notation, and auto-ordering seems dangerous
  • perhaps it isn't doing any ordering? All the reports are in a bucket that are in the right place, and only
    required phases get activated?
  • or does it start from a blank lifecycle and each additional goal overlays additional stuff?
  • does this cause a risk of things not working because there are now three test executions, each with different
    parameters?
  • can we instead do the forked execution, but make use of the execution strategies so things still only execute once
    with identical parameters?
  • but what if another goal modifies some of its parameters?
  • general behaviour is that if something is specified twice now, it is run twice, because of the removal of prereqs
  • inclined to say we do the forking here for now at least.
• @phase vs. lifecycle declaration is a bit arbitrary. eg, should resources:resources always be part of
  process-resources? Why not use the @phase and somehow trigger it's inclusion?
• encapsulate all transfer in mojo fields, use OGNL to translate back to project
  • how would this be specified? does each field that exports provide an @export tag, or does it have an
    in, out, inout specifier? (urgh, CORBA flashback!)