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.
On the other hand, the developers of the external plugin will be responsive to
issues that we flag… so maybe an interim compromise is for us to setup tests
with our edge code against it to cut any future changes off.
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
