[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737444#action_12737444
]
Uwe Schindler commented on LUCENE-1769:
---------------------------------------
Thanks for all your help!
bq. This means that all of the src and test java files in contrib will also be
instrumented by clover, if that is what you want?
Not really, my intention was to only instrument the source files using the
tests (I can see this, that during compilation it tells me that XXX files are
instrumented). This is how it was before.
The <testsources> tag in the clover setup was added, because the
backwards-branch tests (ant test-tag) completely broke the clover run (as
clover was not able to automatically figure out, which are the real test files
that should be run to instrument the source - maybe because the backwards
branch is checked out on the fly using svn). Because of this I added
explicitely the source files to <testsources> in the init task - see my patch.
Since I did this, it works as exspected. I used the already defined variables
for that.
Without this <testsources> you cannot see any instrumentation data generated
during run of tests (see above), it seems, that clover only instruments during
the backwards-branch tests. With the explicit tests in <testsources> it works
as exspected.
bq. I added the <testsources/> element to both the HTML and the XML report
tasks too. This ensures that the coverage of your test cases themselves are
reported in a seperate section of each report.
This is good, because without that clover-report does not see the contrib
tests, only the core tests (during the compilation and instrumentation of
contrib it works, as each contrib is run in a subant. When building the main
report, no subants are involved and the report is only generated at top-level,
where the tests are not available.
bq. Clover 2 does not require the clover.jar to be installed into an Ant Lib,
so I suggest checking it in trunk/lib/ , right next to junit.jar. We will be
generating a new site license for org.apache that can also be committed to your
public svn server, so anyone wanting to develop on Lucene can just use Clover
out of the box, on their desktop.
The problem with that is, that we then have clover.jar inside the source
distribution, which adds 9 MB of extra stuff. Also I am not sure, if it is
good, to also add the clover license to that. And from the legal standpoint, I
am not sure, if it is ok to bundle a non-free product together with Apache
licensed software?
I would like to have the clover.jar outside of the Lucene source distrib as
before and e.g. only enable clover on our hudson build servers. If somebody do
not want to put his clover.jar into the ant build dir, we could add a property
that can be added to the local build.properties file. Or the user can run with
"ant -lib ...". Alternatively we could add a ant task, that download the clover
license and jar from Apache's private Committer SVN. We do this with other JAR
files, too. I will think about it.
I will prepare a patch and merge your's and mine changes and restore the
testsources in the clover-setup task.
bq. although have some test failures on my local machine. I am pretty sure
these are not caused by Clover, however would love for you to double check.
What tests are failing for you? Normally all should pass at the moment (see
build logs at Apache's Hudson).
> Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3
> or better
> ---------------------------------------------------------------------------------------
>
> Key: LUCENE-1769
> URL: https://issues.apache.org/jira/browse/LUCENE-1769
> Project: Lucene - Java
> Issue Type: Bug
> Components: Build
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Attachments: LUCENE-1769.patch, nicks-LUCENE-1769.patch
>
>
> This is a followup for
> [http://www.lucidimagination.com/search/document/6248d6eafbe10ef4/build_failed_in_hudson_lucene_trunk_902]
> 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 properties).
> 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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
