RE: [Cobertura-devel] How can I get involved....

[Mark D. <Mar...@sa...>]

It sounds like you have a good idea of what you want to do.  I would be =
careful to try to keep the data harvesting and the report generation rea=
sonably separate from each other.  Why?  Because historical "change in c=
overage over time" graphs would be really cool, and I think it's somethi=
ng that could be an impressive addition to Cobertura.  If it WAS made a =
part of Cobertura, it seems likely that the data harvesting parts of you=
r code would need lots of changes, but hopefully the report generation s=
tuff could remain largely unchanged.

-Mark 

> -----Original Message-----
> From: Jody Brownell [mailto:jod...@Q1...] 
> Sent: Friday, May 13, 2005 6:56 AM
> To: Mark Doliner
> Cc: cob...@li...; Adam Morgan
> Subject: RE: [Cobertura-devel] How can I get involved....
> 
> Sure does - thanks.
> 
> My first thoughts were - this could be an addon package/application of
> sorts which can use your .ser file or the XML reports (once 
> successfully
> completed). I would prefer to not touch your guys code at all if
> possible and just piggy back on what you have - make enhancements if
> required.
> 
> This implies that, the way users run cobertura now would not change at
> all - providing a single user mode of sorts. Then the new additional
> task (ant?) could be run to export that data to a central or non
> volatile data store. (Data store could be RDBMS, flat file or 
> what have
> you - makes no difference to me - as long as simple and fast).
> 
> Key things for me are, it needs to be extremely simple to install and
> maintain. No over complicated configuration etc - keep it as 
> it is today
> as much as possible.
> 
> Agree about the UI - has to be clean, intuitive, simple and fast. 
> 
> - Be nice to view reports on product? / project / package / 
> class / ...
> hierarchy - as you navigate through the hierarchy - 
> graph/plot for where
> you are
> - plotting lines of code / coverage over time (Jfreechart has 
> some great
> plots)
> - Need to identify and ensure we have the right data in the 
> datastore. A
> few reports which come to mind are
>   - plain coverage stats
>   - plain coverage stats plotted against lines of code
>   - coverage stats of one project/package/class plotted against the
> baseline coverage of all projects (how does this project/package/class
> compare to the running average) ( more advanced :))
> 
> For now - I will focus on keeping it simple with two additional ant
> tasks, one for exporting/updating to non volatile datastore, the other
> for generating reports from that data. I will put together a 
> more formal
> list of features / requirements over the next few days.
> 
> Thoughts?
> 
> -----Original Message-----
> From: Mark Doliner [mailto:Mar...@sa...] 
> Sent: Tuesday, May 10, 2005 12:03 PM
> To: Jody Brownell
> Cc: cob...@li...
> Subject: RE: [Cobertura-devel] How can I get involved....
> 
> *snip*
> 
> > Anywho - the purpose of this email is to see how I can get 
> > involved. One
> > gap in the product which I noticed (and may already be planned) is
> > coverage statistics over time. I was thinking, unless this is on
> > someone's plate already I could start to get familiar with 
> > the code base
> > and put together a plan of attack - an impact of sorts - and 
> > propose to
> > you all.
> 
> *snip*
> 
> > Please let me know if this is of interest. BTW - what is the typical
> > process of getting involved? Hope I am not jumping the gun.
> 
> You're not jumping the gun at all.  I suppose the typical process of
> getting involved is to find something you're interested in
> fixing/improving/adding and writing a patch for it.  I don't know of
> anyone working on statistics over time.  And it's definitely something
> that would be nice to have.  You would definitely want to 
> work with CVS,
> if you plan on making any changes.  Some of the stuff I mention below
> applies to CVS but not to the last release.
> 
> I guess the easy way to do it would be to name the XML 
> reports based on
> the date and time they were created, and then you could parse a
> directory of these files and determine the change over time.  This
> wouldn't even need to be a part of Cobertura--it could be a completely
> separate program.  Or maybe instead of reading the data from the XML
> reports, you could read it directly from cobertura.ser files. 
>  (The ser
> file contains basically the same information as the XML reports.  The
> ser file contains serialized classes from the package
> net.sourceforge.cobertura.coveragedata.  If you choose to go 
> this route,
> you would need to use these classes to read the serialized file.)
> 
> However, it might be better to modify the classes in the coveragedata
> package to natively support a time and date.  I'm not sure how this
> would work exactly.  Maybe you could tag the information in 
> the ser file
> with a datestamp and then zero it out before running the next batch of
> tests.
> 
> I think it is important that this have a good user interface. 
>  How would
> the statistics be displayed?  As a line graph, maybe?  How would the
> user tell Cobertura to create these reports?  Would they specify a
> "start date" and "end date"?  Would the report have a separate display
> for each package?  For each class?  Would it have a way to show
> differences in the source files?
> 
> Does that help you, any?
> 
> -Mark
>