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

[Jody B. <jod...@Q1...>]

Agreed... Plan is to make it part of cobertura - assuming you accept the
patches etc :) I have to get few a number of items at work, then I will
start.

I will be in touch shortly.=20

BTW - is there anything major happening now on HEAD in cvs?

-----Original Message-----
From: Mark Doliner [mailto:Mar...@sa...]=20
Sent: Tuesday, May 17, 2005 4:41 PM
To: Jody Brownell
Cc: cob...@li...; Adam Morgan
Subject: RE: [Cobertura-devel] How can I get involved....

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
reasonably separate from each other.  Why?  Because historical "change
in coverage over time" graphs would be really cool, and I think it's
something 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 your code would need lots of changes, but hopefully the report
generation stuff could remain largely unchanged.

-Mark=20

> -----Original Message-----
> From: Jody Brownell [mailto:jod...@Q1...]=20
> 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....
>=20
> Sure does - thanks.
>=20
> My first thoughts were - this could be an addon package/application of
> sorts which can use your .ser file or the XML reports (once=20
> 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.
>=20
> 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=20
> what have
> you - makes no difference to me - as long as simple and fast).
>=20
> Key things for me are, it needs to be extremely simple to install and
> maintain. No over complicated configuration etc - keep it as=20
> it is today
> as much as possible.
>=20
> Agree about the UI - has to be clean, intuitive, simple and fast.=20
>=20
> - Be nice to view reports on product? / project / package /=20
> class / ...
> hierarchy - as you navigate through the hierarchy -=20
> graph/plot for where
> you are
> - plotting lines of code / coverage over time (Jfreechart has=20
> some great
> plots)
> - Need to identify and ensure we have the right data in the=20
> 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 :))
>=20
> 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=20
> more formal
> list of features / requirements over the next few days.
>=20
> Thoughts?
>=20
> -----Original Message-----
> From: Mark Doliner [mailto:Mar...@sa...]=20
> Sent: Tuesday, May 10, 2005 12:03 PM
> To: Jody Brownell
> Cc: cob...@li...
> Subject: RE: [Cobertura-devel] How can I get involved....
>=20
> *snip*
>=20
> > Anywho - the purpose of this email is to see how I can get=20
> > 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=20
> > the code base
> > and put together a plan of attack - an impact of sorts - and=20
> > propose to
> > you all.
>=20
> *snip*
>=20
> > 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.
>=20
> 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=20
> 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.
>=20
> I guess the easy way to do it would be to name the XML=20
> 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.=20
>  (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=20
> this route,
> you would need to use these classes to read the serialized file.)
>=20
> 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=20
> the ser file
> with a datestamp and then zero it out before running the next batch of
> tests.
>=20
> I think it is important that this have a good user interface.=20
>  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?
>=20
> Does that help you, any?
>=20
> -Mark
>=20