...

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!)