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

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

BTW - what is the target JDK for cobertura? Just wondering what I
version of the JDK I can introduce dependencies for if I need to....

cheers

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

No, there are no major changes happening in HEAD right now.  However,
the changes between 1.2 and HEAD are pretty big--I definitely suggest
developing against CVS HEAD rather than 1.2.
-Mark=20

> -----Original Message-----
> From: Jody Brownell [mailto:jod...@Q1...]=20
> Sent: Tuesday, May 17, 2005 3:55 PM
> To: Mark Doliner
> Cc: cob...@li...; Adam Morgan
> Subject: RE: [Cobertura-devel] How can I get involved....
>=20
> Agreed... Plan is to make it part of cobertura - assuming you=20
> accept the
> patches etc :) I have to get few a number of items at work,=20
> then I will
> start.
>=20
> I will be in touch shortly.=20
>=20
> BTW - is there anything major happening now on HEAD in cvs?
>=20
> -----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....
>=20
> It sounds like you have a good idea of what you want to do. =20
> 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. =20
> If it WAS
> made a part of Cobertura, it seems likely that the data=20
> harvesting parts
> of your code would need lots of changes, but hopefully the report
> generation stuff could remain largely unchanged.
>=20
> -Mark=20
>=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=20
> 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=20
> 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=20
> 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=20
> 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=20
> 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=20
> 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=20
> 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=20
> 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=20
> 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=20
> 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=20
> 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=20
> 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=20
> 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
>=20