> -----Original Message-----
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: lundi 13 juin 2005 02:05
> To: Maven Developers List
> Subject: Re: [m2] "Verification" phase required?
>
> Are you now doing these checks as part of a normal "m2 install" build?
Yes
> That is probably a bit heavier than I'd have thought it should be, but
> probably a valid use case.
It's a test so I guess it's "normal" you may wish to run it in the "release"
lifecycle as part of "m2 install".
> Previously, you had talked about running it as "m2 clover:clover" and
> doing all of those checks in there.
Hmm... I had forgotten about that. I think that there is a valid use case
for having clover:check as part of "m2 install" even though it's a bit heavy
as you say. But it'd be optional of course. The same applies for checkstyle,
pmd, simian, etc.
> Do you think you could have a go at designing how you think this will be
> used, so we can compare it to the lifecycle design and propose
> solutions? Some of this still needs to be implemented, which I'll be
> working on this week.
>
> Please enumerate all the use cases (including reports, as even if you
> aren't doing it now it is important), how the user will configure it and
> how the user will run it.
Yep, this is what I've done yesterday while implementing the clover plugin.
I've found only 2 use cases so far:
Use case 1:
===========
- Run "m2 site:site"
- It generates the clover report by calling the clover:report goal
- Still open: whether we spawn a "m2 install" lifecycle or not. Maybe we
shouldn't by default so that "m2 site:site" generates a report of what is
currently in the existing clover database. The user would run whatever
he/she wants before that (m2 install site). Or maybe we should check the
freshness of the clover database file against the source files (main and
test) and regenerate only if a source is newer that the clover db. I'm open
here. The same question will arise for the junit-report plugin in the
future.
- If the project has modules, clover:report will merge the clover databases
of the modules to generate an aggregated clover report. I guess this could
be turned on/off by a configuration property.
Use case 2:
===========
- Run "m2 install"
- It runs clover:instrument in the generate-sources phase and then the other
phase depending on the packaging type
- It runs clover:check as part of the "verification" phase (I've currently
bound it to the integration-tests phase while we discuss it). This is run
only if it is activated:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-clover-plugin</artifactId>
<version>1.0-SNAPSHOT</version>
<configuration>
<activated>true</activated>
<targetPercentage>50</targetPercentage>
</configuration>
</plugin>
</plugins>
</build>
- It does NOT generate any report. For that you'll need to explicitely call
"m2 clover:report" or run the site generation (see use case 1).
- If the "activated" property is false, "m2 install" will not clover
anything.
Caveats:
--------
- Should we have 2 sets of sources and should we make sure that the clover
plugin does not affect the main sources so that we cannot mistakenly package
for production clovered sources? If so, we'll need to spawn a full new "m2
install" lifecycle from within the clover plugin. I guess we need this. I
haven't implemented it yet. ATM my clover plugin clovers the main sources
and not a copy. I'll need some help for how to implement this.
Use case 3:
===========
- Run "m2 clover:check" or "m2 clover:report"
- This would work even if the "activated" config property is false.
- Users of this use case will typically set "activated" to false so that
clover doesn't run automatically as part of "m2 install".
WDYT?
[snip]
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
