+1 for pulling. I have a feeling some people will view not working cobertura plugin as a regression even though it isn't...
Cheers! On Fri, Sep 14, 2012 at 2:06 PM, Hans Dockter <[email protected]> wrote: > > > On Fri, Sep 14, 2012 at 1:42 PM, Luke Daley <[email protected]> > 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. > > > I think there is no question that we need a coverage solution in core. It is > something many projects obviously need. The reason why we haven't added it > in the earlier days was that it is a perfect candidate for initializer and > finalizer tasks. So my idea was always to have this a the first use case for > those enhancements. But I think we shouldn't wait for this to happen. > >> >> >> 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. > > > It is a missing feature affecting many of our users. On the other hand our > story line is stuffed. I think I would trade it for quite a few other > stories but none of the major 4 or so ones. > >> 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. > > > I fully agree with the last paragraph. > > Hans > >> >> >> -- >> Luke Daley >> Principal Engineer, Gradleware >> http://gradleware.com >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > -- Szczepan Faber Principal engineer@gradleware Lead@mockito --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
