Brett Porter wrote:
- if in <reports> the configuration applies to the report, which may
be different to the mojo in <build/> if the plugin is executed
there. So we need that separate section.
I think it's more usable if user configure reports only in <reports>.
Ah yes, I remember now. I was thinking that configuration in reports
applied to both, but configuration in plugins only applied to execute
(and could override the others). Does that sounds reasonable?
I can't think to any use case for override reports configuration.
I think user will run a specific report mojo for see the result at a
specific time, be the real report will be generated by the site plugin
and deploy with others.
I think we need it because some reports need to execute some other
mojo like compile for clover and jcoverage, and surefire for test report.
We can have a similar lifecycle to the actual, and we put the site
mojo in place of package
The problem with this is that most of the reports don't play together -
eg if you were added both jblanket and clover to get some different
coverage metrics, they might not work together. So I was still thinking
each report would fork its own lifecycle, and rely on timestamp checking
to not redo work unnecessarily (ie only run tests again if the source
classes are different).
oh yes, I didn't think to this.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
