lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] Commented: (LUCENE-1769) Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better
Date Wed, 05 Aug 2009 08:50:14 GMT


Uwe Schindler commented on LUCENE-1769:

> Hi Uwe,
> I noticed that in your patch to integrate Clover, you also excluded
> the following from instrumentation:
> <exclude name="org/apache/lucene/analysis/
>" /><!-- Class too large for clover -->
> Do you remember the error you were getting when Clover tried to
> instrument this file?
> I was getting:
> [clover] /Users/niick/work/hudson/plugins/clover/work/jobs/Lucene/
> workspace/trunk/src/test/org/apache/lucene/analysis/
> '"', found '?'

Hi Nick,

this was the same error I got. I thought it may have to do with charset encoding (how does
Clover detect the encoding? from the javac parameters like -source 1.4 and so on?). I have
seen you added an encoding parameter to clover-setup, but I was not sure, which encoding was
meant (encoding of source files, encoding of html report,... - as there was no documentation
about it in clover's docs).

In the last patch on the JIRA issue, I already included the large ASCIIFoldingFilter to instrumentation
(in the first patch, I only preserved all config from the Clover 1.x analysis to be sure to
have a working FileSet). I then noticed, that Clover 2.4 was able to instrument this file
and removed the exclusion.

If the charset bug is fixed in 2.6, I will then remove the ASCIIFolding Test exclusion from
the patch, too.

Did you review and tried out my last patch?

> Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better
> ---------------------------------------------------------------------------------------
>                 Key: LUCENE-1769
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 2.9
>            Reporter: Uwe Schindler
>         Attachments: clover.license, LUCENE-1769.patch, LUCENE-1769.patch, nicks-LUCENE-1769.patch
> This is a followup for []
> The problem with clover running on hudson is, that it does not instrument all tests ran.
The autodetection of clover 1.x is not able to find out which files are the correct tests
and only instruments the backwards test. Because of this, the current coverage report is only
from the backwards tests running against the current Lucene JAR.
> You can see this, if you install clover and start the tests. During test-core no clover
data is added to the db, only when backwards-tests begin, new files are created in the clover
db folder.
> Clover 2.x supports a new ant task, <testsources> that can be used to specify the
files, that are the tests. It works here locally with clover 2.4.3 and produces a really nice
coverage report, also linking with test files work, it tells which tests failed and so on.
> I will attach a patch, that changes common-build.xml to the new clover version (other
initialization resource) and tells clover where to find the tests (using the test folder include/exclude
> One problem with the current patch: It does *not* instrument the backwards branch, so
you see only coverage of the core/contrib tests. Getting the coverage also from the backwards
tests is not easy possible because of two things:
> - the tag test dir is not easy to find out and add to <testsources> element (there
may be only one of them)
> - the test names in BW branch are identical to the trunk tests. This completely corrupts
the linkage between tests and code in the coverage report.
> In principle the best would be to generate a second coverage report for the backwards
branch with a separate clover DB. The attached patch does not instrument the bw branch, it
only does trunk tests.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message