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. 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. Thinking more about this… This particular issue is just part of it, and we are unlikely to break it in the same way again soon. The core issue was that something broke due to a change we made without us knowing. That is, we have no guarantee that a gradle release won't break the use of coberura for many users (there's a secondary in that there's no clear choice for coberura support for users). So, the decision is about how much we care about coberura support. Is it enough that we want to be quite sure that all Gradle users can use coberura with Gradle releases we put out? I think we're all saying yes, but maybe not enough to displace something else in the priority list.
