On Thu, Jul 30, 2009 at 4:51 AM, Uwe Schindler<u...@thetaphi.de> wrote: >> I'm guessing it was the empty source file I accidentally left in for >> LUCENE-1754, that Hoss removed (thanks!). I think clover saw that as >> an attempt to instrument a source in the empty-string package. >> >> I'm unfamiliar w/ how to configure clover, but I agree we should make >> sure it's testing coverage for our "normal" unit tests. Rather than >> turn it off for test-tag, can we measure coverage of all tests >> (test-tag, test-core, test-contrib)? >> >> Is there someone familiar w/ clover who can look into this? > > I found out that clover-setup supports a special advanced tag > "<testsources>": > <testsources> is an Ant fileset which should only be used if Clover's > default test detection is not adequate. Clover's default test detection > algorithm is used to distinguish test cases if this element is omitted.
That sounds promising! Atlassian actually proactively contacted me about this build failure (how responsive is that!), offering to look into this "zero bytes source file issue", upgrade Apache's license to clover 2.0 and work out a patch for Lucene to switch to 2.0. I'll open an issue once they send the patch over. > And it seems that clover uses the backwards tests and nothing else. I > install clover locally and try out. I will then open an issue. We should definitely fix that. I think it's best to instrument both the trunk's tests and the back-compat tests if we can. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org