On 15/09/2012, at 8:45 AM, Luke Daley wrote: > > > > > On 14/09/2012, at 11:11 PM, Adam Murdoch <[email protected]> wrote: > >> >> On 14/09/2012, at 9:42 PM, Luke Daley wrote: >> >>> Hi, >>> >>> Gradle 1.2 broke Cobertura support for at least two known ways of using >>> Cobertura with Gradle. A quick google found four different approaches to >>> using Cobertura with Gradle, and I suspect there are more out there. >>> >>> I'm wondering if we should pull support for this into core, under the same >>> grounds that caused us to pull check style support into core. That is, it's >>> a strategic advantage to have a working, capable, tested, documented >>> solution for code coverage. >>> >>> To relieve the 1.2 issue, I did a fair bit of work on >>> https://github.com/Mapvine/gradle-cobertura-plugin. if we were going to >>> pull something in, I'd be inclined to use this as the base. Though, I not >>> Peter has done some work on this kind of thing in the past so he may have a >>> better starting base. My estimate would be that pulling in that code would >>> require about 2 - 3 days to get it to completion (some refactorings, >>> support for merged reports, improved test coverage and docs). It's not that >>> far off now, but needs work unquestionably. >>> >>> We have two opposing tensions here; not wanting to grow the distribution >>> and wanting to have a reliable code coverage solution. I'm inclined to >>> favour pulling it in, because we can always push it out when we have a >>> better story for breaking up the distribution. It's challenging/expensive >>> to meet the goal of having a reliable code coverage solution without >>> pulling it into core right now. >> >> Adding Cobertura support to core is certainly something I'd like to do. >> >> However, given that the immediate issue is looking like a problem with >> testing, rather than using the plugin, we might instead add a better way to >> test plugins and build logic earlier, and Cobertura support in core later. > > This is a good point. > > If we completely shield the outside world from changes to our internal > dependencies then we completely remove the risk of this happening again with > anything in the future. > >> My feeling is that this would offer better pain relief to more people than >> moving a mostly-working-but-not-quite-finished plugin to core. > > I think it's a better long term strategy, but probably not short term. > > Also, we shouldn't just pull it into core without work. So it would be a > finished plugin if it comes in, or it doesn't come in.
Let's put both things on the wish list for the 1.4 release and see what falls out of the planning. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
