Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3


Do other reports require anything additional?

  • this executes the test goal, no change in parameters


  • 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

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