On Wed, May 29, 2013 at 7:55 PM, Nick Williams <[email protected]> wrote: > > On May 29, 2013, at 12:34 PM, Christian Grobmeier wrote: > > On Wed, May 29, 2013 at 5:41 PM, Nick Williams > <[email protected]> wrote: > Anyway +1 on slow + right. > > I'm actually going to disagree. Gary described it as "hours vs. minutes." As > a developer with lots of work and $work to do, if code coverage adds minutes > to the build, I'm going to run it and often. If it adds hours to the build > I'm not going to run it. Ever. Not even one single time ever. It will never > get run.
We have Sonar for running it: https://analysis.apache.org/dashboard/index/111296 > "Right" is relative. I've never seen a code coverage tool that didn't have > bugs. I've never seen software that didn't have bugs. Everywhere I'm > searching for alternatives to Emma I'm seeing "Use JaCoCo, it's perfect!" > Clearly it has a wide user base and enjoys good support. It is actively > maintained. It actually appears to be a fork of Emma or based on Emma > somehow (http://www.eclemma.org/). If we find that code coverage on a > particular class is incorrect, I think saying "use something else that takes > orders of magnitude longer because of a bug" isn't the correct solution. > Instead, I would suggest that the correct solution is reporting, helping > identify, and helping fix the bug. > > After all, wouldn't you want someone to help find and fix bugs in Log4j > instead of just switching to Logback else because they found a bug and don't > want to be bothered with reporting it? For me, Code Coverage does only little for fixing bugs. Unit tests are not good just because they are there. They can run a code multiple times without identifying a bug. With a unit coverage of 58,2% I don't think devs are running code coverage for everything they write. Maybe it's preventing people from contributing, I don't know. I hardly can imagine. I just know, last time I build log4j 2 it didn't took me hours. > I vote JaCoCo, personally. I leave it up to the actual code contributors to decide. Basically my 2 cents were just my take on that, but I have not build it so often that I am going to vote on it. Cheers Christian PS: I never used JaCoco, but Emma and Cobertura > > Nick > > > > Nick > > > > On May 29, 2013, at 10:03 AM, Gary Gregory wrote: > > > I thought Emma was unmaintained since 2005? > > http://sourceforge.net/projects/emma/files/ > > > Gary > > > > On Wed, May 29, 2013 at 10:52 AM, Nick Williams > > <[email protected]> wrote: > > > I'm actually going to go out on a limb here and say that we shouldn't use > > either. > > > I'm familiar with two code coverage tools, personally. IntelliJ IDEA > > coverage (kind of free but doesn't support Maven) and Emma Coverage (free > > and supports Maven). I've used Emma extensively. It's extremely accurate, > > and it's fast. I note three projects below with approximate time with and > > without Emma: > > > Project #1: 550 tests > > Build time without Emma: ~3 minutes > > Build time with Emma: ~4.5 minutes > > > Project #2: 1176 tests > > Build time without Emma: ~4.5 minutes > > Build time with Emma: ~6.5 minutes > > > Project #3: 3174 tests > > Build time without Emma: ~ 14 minutes > > Build time with Emma: ~ 18 minutes > > > I'd highly recommend we go with Emma instead. It has a Maven plugin: > > http://emma.sourceforge.net/plugins/index.html > > > Nick > > > On May 29, 2013, at 9:07 AM, Gary Gregory wrote: > > > The Commons Math folks want to run JaCoCo because it is much faster for > > them than Cobertura (hours vs. minutes according to them). The problem is > > that JaCoCo reports 0% code coverage in certain cases and this is a > > documented issue that does not look easy to fix. So in my mind, slow and > > right is better than fast and wrong. > > > Gary > > > > On Wed, May 29, 2013 at 9:57 AM, Ralph Goers <[email protected]> > > wrote: > > > I didn't follow the conversation on the Commons list. What advantage(s) > > does JaCoCo have over Cobertura? Is there a need to run both or could we > > just standardize on one of them. I believe the Cobertura plugin runs during > > the site build so if JaCoCo was the same I'm not sure why we would need a > > toggle, unless we only wanted to run a code coverage report. > > > Ralph > > > On May 28, 2013, at 6:14 PM, [email protected] wrote: > > > Author: ggregory > > Date: Wed May 29 01:14:18 2013 > > New Revision: 1487179 > > > URL: http://svn.apache.org/r1487179 > > Log: > > Enable code coverage. A comment in the POMs used to say this was broken > > with the 2.2 Cobertura plugin, but it works just fine with 2.5.2. To > > consider: Should we do like Apache Commons and provide a toggle to run > > JaCoCo too? > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > > E-Mail: [email protected] | [email protected] > > Java Persistence with Hibernate, Second Edition > > JUnit in Action, Second Edition > > Spring Batch in Action > > Blog: http://garygregory.wordpress.com > > Home: http://garygregory.com/ > > Tweet! http://twitter.com/GaryGregory > > > > > > > -- > > E-Mail: [email protected] | [email protected] > > Java Persistence with Hibernate, Second Edition > > JUnit in Action, Second Edition > > Spring Batch in Action > > Blog: http://garygregory.wordpress.com > > Home: http://garygregory.com/ > > Tweet! http://twitter.com/GaryGregory > > > > > > > -- > http://www.grobmeier.de > https://www.timeandbill.de > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- http://www.grobmeier.de https://www.timeandbill.de --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
