Maven 1.x Clover Plugin

Stop Clover re-running tests if they've already run

Details

  • Type: Wish Wish
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.6
  • Fix Version/s: 1.7
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

If both the junit-report and clover-report are registered the tests execute twice. Would it be possible to either provide a setting to disable this or detect whether tests have already been run?

This might be similar to the property in the Cactus plugin - cactus.execute.during.report.

Thanks,
Matt.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Vincent Massol added a comment -

Hi Matt,

Yes, the tests are executed twice but not in the same condition. One time it is without clovering on (i.e. the source code is not instrumented) and the second time clovering is on, the code is instrumented and the tests are generating clover data which are then used by the clover report to produce some HTML file.

I'm probably missing something though...

Show
Vincent Massol added a comment - Hi Matt, Yes, the tests are executed twice but not in the same condition. One time it is without clovering on (i.e. the source code is not instrumented) and the second time clovering is on, the code is instrumented and the tests are generating clover data which are then used by the clover report to produce some HTML file. I'm probably missing something though...
Hide
Permalink
Matt Read added a comment -

It's been some time since I posted this but from memory I thought that once the clover report was registered, all compilations had the effect of instrumenting the code. Are suggesting that code actually gets completely recompiled on the second (clover) run of the tests?

If this is true then with just a fairly comprehensive test suite on a medium sized application, my build is simply doing too much stuff. On a larger application it becomes impractical to use Maven to get my build metrics using continuous integration.

On an XP/Agile project I regularly allocate time to refactor/optimise my test suite in order to decrease the execution time and therefore encourage regular runs of the tests. The impact of running the suite multiple times can be huge.

Show
Matt Read added a comment - It's been some time since I posted this but from memory I thought that once the clover report was registered, all compilations had the effect of instrumenting the code. Are suggesting that code actually gets completely recompiled on the second (clover) run of the tests? If this is true then with just a fairly comprehensive test suite on a medium sized application, my build is simply doing too much stuff. On a larger application it becomes impractical to use Maven to get my build metrics using continuous integration. On an XP/Agile project I regularly allocate time to refactor/optimise my test suite in order to decrease the execution time and therefore encourage regular runs of the tests. The impact of running the suite multiple times can be huge.
Hide
Permalink
Vincent Massol added a comment -

General considerations:

I've always found this to be an issue with Maven reports: they not only create a report but they do also perform the logic to create the report data. Thus if you build your project and then generate the site you'll have run twice the build logic that creates the report data.

For your problem:

The only solution I can think of is to have an execute.during.report flag (as you mentioned) so that instrumentation would only happen if this flag is set. If not, the report will take whatever data has already been generated in the Clover database file (which could amount to nothing).

Now in term of sharing the compilation with the junit report, it will be possible by doing the following:

  • set maven.clover.execute.during.report = false
  • call 'maven clover:on site' instead of 'maven site'

Would that be ok with you?

Show
Vincent Massol added a comment - General considerations: I've always found this to be an issue with Maven reports: they not only create a report but they do also perform the logic to create the report data. Thus if you build your project and then generate the site you'll have run twice the build logic that creates the report data. For your problem: The only solution I can think of is to have an execute.during.report flag (as you mentioned) so that instrumentation would only happen if this flag is set. If not, the report will take whatever data has already been generated in the Clover database file (which could amount to nothing). Now in term of sharing the compilation with the junit report, it will be possible by doing the following:
  • set maven.clover.execute.during.report = false
  • call 'maven clover:on site' instead of 'maven site'
Would that be ok with you?
Hide
Permalink
Matt Read added a comment -

Yep, that would solve my immediate (well, immediate 7 months ago) problems.

I agree with you completely on your general consideration point. For the kind of projects that I'm generally involved with, Maven simply will not scale sufficiently to support continuous integration. I find myself slipping back to nightly builds for more and more of the goals as the codebase grows.

Show
Matt Read added a comment - Yep, that would solve my immediate (well, immediate 7 months ago) problems. I agree with you completely on your general consideration point. For the kind of projects that I'm generally involved with, Maven simply will not scale sufficiently to support continuous integration. I find myself slipping back to nightly builds for more and more of the goals as the codebase grows.
Hide
Permalink
Vincent Massol added a comment -

Done. Added new maven.clover.execute.during.report (defaults to true).

Show
Vincent Massol added a comment - Done. Added new maven.clover.execute.during.report (defaults to true).

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.