I tried mvn clover:instrument clover:clover and it seems to work fine so thats just about as easy as cobertura, apart from having to mess about with a license. AFAICT the Clover Eclipse plugin doesn't support Eclipse 3.2 yet so I can't use it. Requiring a license is a drawback, especially for non-committers who would need to go apply for their own free one, so cobertura seems best to me.
Do we really need to choose one over the other? As we're just running this on our own local environment can't we just let everyone choose whichever they like? ...ant On 9/7/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
I tried both, they were both easy to run and seemed to generate similar results. To run clover: # add <jdk>1.5 to the plugin config in the pom $ mvn clover:instrument clover:clover To run cobertura: $ mvn cobertura:cobertura Both seem to integrate well with Maven but Clover also integrates with IDEA and Eclipse so I'm tempted to go with that - any objections? -- Jeremy On Sep 5, 2006, at 8:14 AM, Jeremy Boynes wrote: > On Aug 16, 2006, at 2:49 PM, Jim Marino wrote: >>> 2) SCA Core (spi, core, hostutil, test, plus apis once that >>> refactor is done) >>> Features I would like to see complete before we consider this >>> stable are: >>> Class loading changes >>> Integration of databinding framework >>> Support for async callbacks >>> Support for complex properties >>> Transitive dependency support >>> >> I'd also like to see much better test coverage than what we have. >> This is hard to quantify, but while code coverage does not >> guarantee good tests, it is an indicator. So, to have a metric, >> I'd like to see core (and other extensions) at 75% coverage when >> run through Clover. I picked Clover since it is a decent tool and >> license-friendly but if someone would like to suggest an >> alternative we could look at it as well. > > I think this goal is worth pursuing and would add that as a > criteria for the next release. Apache has a license for Clover so > we can all use it, Cobertura would be another alternative - any > preference here? Whatever we use, I don't think this should be part > of the build right now (although that could change later) but that > the tool should be run periodically and the results published > somewhere (e.g. on our site). > > Now Jim here only mentioned the core but this would apply to other > extensions as well - I would be inclined to extend this requirement > to any extension we consider "baseline" - any objections? > > -- > Jeremy > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
