[
https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737671#action_12737671
]
Uwe Schindler commented on LUCENE-1769:
---------------------------------------
This discussion was on java-dev, I copy it here for completeness:
> : I didn't realize the nightly build runs the tests twice (with & w/o
> : clover); I agree, running only with clover seems fine?
>
> i'm not caught up on this issue, but i happen to notice this comment in
> email.
>
> the reason the tests are run twice is because in between the two runs we
> package up the jars. clover instruments all the classes, so if we only
> ran hte tests once (w/clover), and then packaged the jars the nightly
> builds would include clover instrumented bytecode.
>
> if you look at the old Jira issues about clover this is discussed there.
>
> -Hoss
This is correct but still inefficient. The current workflow is:
- Checkout svn
- Build the source package with ant
- Build the maven artifacts (which compiles all classes)
- Then ant nightly is called, which builds the binary package and runs tests ->
this could be optimized to only build the binary package
- ant clean
- ant nightly with clover enabled -> This packages the binaries again, but does
not copy them. This is also not the best. This step should simple do ant test
with clover
- build the clover report
I only want to remove the call to the (I call it deprecated "nightly" target,
which is a relict from the time before Hudson and replace by "package" in the
first run and to "ant test" for the clover enabled version. The build would run
two times faster.
> 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, 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: [email protected]
For additional commands, e-mail: [email protected]
