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: >> Wow. You'd think they could at least put a notice on their website that it's >> unmaintained. I've been using it how long??? Over a year... >> >> In theory, we should still be able to use it. We're using Java 6, which it >> supports. I've never had a single problem with it. However, if users >> compiled Log4j locally with Java 7 code coverage would cause all tests to >> fail, and that is not desirable. >> >> So, with that I rescind my suggestion. >> >> Really? Why on earth don't they have a notice on their website that it's no >> longer maintained??? > > Because... its not maintained ;)
Well, that's not exactly true. No files have been checked in to source control. But the developers are active: http://sourceforge.net/p/emma/discussion/373867/ But for some reason they're not committed any code. It appears that Java 7 is supported ... just not from the downloads. Somebody has access to update the website. > > 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. "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? I vote JaCoCo, personally. 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] >
