I'm not sure if generalisation of n coverage tools is high priority on its own. If we offer cobertura as a built-in plugin, some generalisation is unavoidable for clarity and maintainability. It would be nice to have a really good cobertura plugin, but I'd rather it to be maintained by the community :) Also, the design of the generic coverage api probably requires considerable effort. Short term, I'd rather we focus on other things (core platform, missing plugins, better automation for community plugins, etc.). Long term, it might be nice :)
>For now Jacoco does not provide enough options to filter out branched related to assertions and specific "unreachable" branches in our code. Perhaps it's worth reaching out to jacoco community about this one. Thanks for reaching out! On Thu, Oct 31, 2013 at 12:24 PM, Mark Koops <gradle-...@mkoops.nl> wrote: > Hi, > > In our team we are migrating from Ant to Gradle and in our Ant build we > determine code coverage using a custom build of Cobertura. > > I have given Jacoco a change as being available as build-in plugin, but > the differences are too big. > For now Jacoco does not provide enough options to filter out branched > related to assertions and specific "unreachable" branches in our code. > > So I would like to setup Cobertura code coverage detection in our Gradle > build. > Some time ago, I have been experimenting with > https://github.com/eriwen/gradle-cobertura-plugin, but not to full > success at that time. I will check again. > > But I would to work on a build-in Cobertura plugin side-by-side with > Jacoco. Then you have a choice which one to use. > > How about: generalizing the Jacoco plugin code to a generic java code > coverage plugin base class with two derived implementations, one for Jacoco > and one for Cobertura. > > Thanks, > > --Mark > > > > -- Szczepan Faber Principal engineer@gradle; Founder@mockito Join me at the Gradle eXchange 2013, Oct 28th in London: http://skillsmatter.com/event/java-jee/gradle-exchange-2013
