...
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!)
- how would this be specified? does each field that exports provide an @export tag, or does it have an