cobertura-devel — General questions about using and developing Cobertura.

RE: [Cobertura-devel] javanscc jar dependencies ?

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

 > -----Original Message-----
> From: cob...@li...=20
> [mailto:cob...@li...] On=20
> Behalf Of Czechowski, Igor
> Sent: Wednesday, May 18, 2005 11:56 AM
> To: Cobertura-devel
> Subject: RE: [Cobertura-devel] javanscc jar dependencies ?
>=20
> I came up with the two ideas.=20
>=20
> First, what do you think about including other source code metrics
> javancss provides in the cobertura report ?

I'm not sure I see a big advantage to that.  I think I'd rather see work =
being done more toward fixing the bugs that already exist, than toward =
merging in lots of code that isn't really related.

I'm not against having a nice, unified view of lots of fancy metrics, =
but I think that would be handled better as an independent project than =
as an addition to Cobertura.  I guess I'm a student of the "write a =
program to do one thing and do it well" mentality.

> So the scenario would be to produce the entire html report=20
> and only the
> package overview of the xml one. Then I would use transformation to
> produce the html page for the cruisecontrol. I can merge the existing
> xml report but I thing it's a little bit over reporting for me at the
> current state.

Hmm.  I guess you could accomplish something along these lines by =
generating the XML report then merging it into the CruiseControl build =
log (the same way Junit XML is merged).  Then you would need to add an =
xsl transform for displaying a coverage summary to the CruiseControl =
build results page.

-Mark

RE: [Cobertura-devel] Newbie: Multiple Source Directories

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

I believe emails sent to this list DO get copied back to the sender.  =
They do for me, anyway.
-Mark=20

> -----Original Message-----
> From: Seigel, James [mailto:Jam...@av...]=20
> Sent: Thursday, May 19, 2005 3:08 PM
> To: Mark Doliner
> Cc: cob...@li...
> Subject: RE: [Cobertura-devel] Newbie: Multiple Source Directories
>=20
> Thank you. =20
>=20
> Can you also confirm that emails sent to this list don't get=20
> copied back
> to the sender?  I sent in a dup this morning because I didn't see this
> one....and I didn't see that one either....
>=20
> Cheers
> James.
>=20
> -----Original Message-----
> From: Mark Doliner [mailto:Mar...@sa...]=20
> Sent: Thursday, May 19, 2005 1:02 PM
> To: Seigel, James
> Cc: cob...@li...
> Subject: RE: [Cobertura-devel] Newbie: Multiple Source Directories
>=20
> It is not currently possible to point the reporting tool to read from
> multiple source directories.  It's definitely something that should be
> supported in the future, but there is no ETA.  This is covered in
> feature request 117048:
> https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1170
> 482&group_
> id=3D130558&atid=3D720018
>=20
> Yes, copying all the source to a new, temporary directory is a good
> workaround.
>=20
> -Mark=20
>=20

RE: [Cobertura-devel] Newbie: Multiple Source Directories

[Seigel, J. <Jam...@av...>]

Thank you. =20

Can you also confirm that emails sent to this list don't get copied back
to the sender?  I sent in a dup this morning because I didn't see this
one....and I didn't see that one either....

Cheers
James.

-----Original Message-----
From: Mark Doliner [mailto:Mar...@sa...]=20
Sent: Thursday, May 19, 2005 1:02 PM
To: Seigel, James
Cc: cob...@li...
Subject: RE: [Cobertura-devel] Newbie: Multiple Source Directories

It is not currently possible to point the reporting tool to read from
multiple source directories.  It's definitely something that should be
supported in the future, but there is no ETA.  This is covered in
feature request 117048:
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1170482&gro=
up_
id=3D130558&atid=3D720018

Yes, copying all the source to a new, temporary directory is a good
workaround.

-Mark=20

RE: [Cobertura-devel] Newbie: Multiple Source Directories

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

It is not currently possible to point the reporting tool to read from =
multiple source directories.  It's definitely something that should be =
supported in the future, but there is no ETA.  This is covered in =
feature request 117048:
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1170482&gro=
up_id=3D130558&atid=3D720018

Yes, copying all the source to a new, temporary directory is a good =
workaround.

-Mark

> -----Original Message-----
> From: cob...@li...=20
> [mailto:cob...@li...] On=20
> Behalf Of Seigel, James
> Sent: Wednesday, May 18, 2005 11:14 AM
> To: cob...@li...
> Subject: [Cobertura-devel] Newbie: Multiple Source Directories
>=20
> Hello!
>=20
> I am new to the list and to cobertura and have a quick=20
> question that I couldn't seem to find a clear answer to.
>=20
> I am wondering if it is possible to point the reporting tool=20
> to read from multiple source directories. For example ./src &=20
> ./test  or if you are trying to get a larger picture of=20
> coverage for multiple frameworks all linked into one report?
>=20
> Or does one have to do some heavy lifting and temporarily=20
> copy all the source into one directory and then run the tool?=20

RE: [Cobertura-devel] Source code in the repository

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

The code in CVS is current development code, and is newer than 1.2.  =
When we release 1.3 (hopefully late tonight) it will be a snapshot of =
CVS.
-Mark
=20

> -----Original Message-----
> From: cob...@li...=20
> [mailto:cob...@li...] On=20
> Behalf Of Czechowski, Igor
> Sent: Thursday, May 19, 2005 11:35 AM
> To: cob...@li...
> Subject: [Cobertura-devel] Source code in the repository
>=20
> Hello,
>=20
> I've pulled a source code out of the
> cvs.sourceforge.net:/cvsroot/cobertura and it looks different then the
> one I can find in the 1.2 release ?
> Does any one knows why and can I expect the newer code will be in the
> repository ?
>=20
> Thanks
>   Igor

[Cobertura-devel] Multiple Source Directories

[Seigel, J. <Jam...@av...>]

Sorry if this is a repeat, I didn't see it come through the other day.

=20

=20

Hello!

=20

I am new to the list and to cobertura and have a quick question that I
couldn't seem to find a clear answer to.

=20

I am wondering if it is possible to point the reporting tool to read
from multiple source directories. For example ./src & ./test  or if you
are trying to get a larger picture of coverage for multiple frameworks
all linked into one report?

=20

Or does one have to do some heavy lifting and temporarily copy all the
source into one directory and then run the tool?=20

=20

Cheers

=20

=20

---
James Seigel
Software Developer
Avocent Mobile Solutions
Direct: 403.355.2574
Toll Free: 866.602.2002

=20

[Cobertura-devel] Source code in the repository

[Czechowski, I. <Igo...@sa...>]

Hello,

I've pulled a source code out of the
cvs.sourceforge.net:/cvsroot/cobertura and it looks different then the
one I can find in the 1.2 release ?
Does any one knows why and can I expect the newer code will be in the
repository ?

Thanks
  Igor

[Cobertura-devel] bug while merging

[Harish P. <hpr...@co...>]

hi,

We are trying to merge two cobertura.ser files which has the same code base.
one cobertura.ser files is  created  when running junit and the other is
created when weblogic server is stopped which are created in two different
directories.
Apparently when trying to merge we found that it is just overwriting the
other. for e.g. Junit calls a Delegate class which happens to have a code
coverage of 40%.
This Delegate class calls the server classes and no Delegate class is called
through the server. So the code coverage for this Delegate class is 0% in
the cobertura.ser
generated by the weblogic.

Now when we are trying to merge this both ideally it should been given 40%
but it gives 0%.  Going through the source code we found that in
CoverageData.java
we have a method which merges the two files as given below. 
	public void merge(CoverageData coverageData)
	{	lines.putAll(coverageData.lines);
		conditionals.putAll(coverageData.conditionals);
		methodNamesAndDescriptors.addAll(coverageData
				.getMethodNamesAndDescriptors());
	}
In the above code lines is a HashMap object

The lines.putAll(coverageData.lines) just overwrites the data. 

The above method could be modified as given below.

	public void merge(CoverageData coverageData)
	{	Set keySet = lines. keySet();

		Iterator iterator = keySet.iterator();
		while(iterator.hasNext()) {
			Integer lineNumber = (Integer) iterator.next();
			LineInformation l1 =
(LineInformation)lines.get(lineNumber);
			LineInformation l2 =
(LineInformation)coverageData.lines.get(lineNumber);
			long hits1 = l1.getHits();
			long hits2 = l2.getHits();

			if(hits2>hits1) {
				lines.put(lineNumber,l2);
			}
		}

		//lines.putAll(coverageData.lines);
		conditionals.putAll(coverageData.conditionals);
		methodNamesAndDescriptors.addAll(coverageData
				.getMethodNamesAndDescriptors());
	}


Let me know if anyone has a better solution.

Regards
Harish




>  -----Original Message-----
> From: 	Harish Prabhakara  
> Sent:	Tuesday, May 17, 2005 4:04 PM
> To:	'cob...@li...'
> Cc:	Iyer, Tejas; Satyadarshi Mishra; Bothra, Naveen
> Subject:	improper codecoverage report
> 
> hi,
> 
> We are trying to do a code coverage analysis for an application deployed
> under Weblogic 8.1 server. The application is been tested
> using Junit as well as HttpUnit Test Cases. While doing the code coverage
> analysis we found that the code coverage is been
> reported for those classes which has been called through Junit. Code
> coverage for those Classes which are run under Weblogic 
> environment or under HttpUnit environment is not shown as covered. For
> E.g. Let us say that we have got a Delegate class
> which calls  a service. This service is an EJB which is been deployed in
> the Weblogic server. This Ejb in turns calls some VOAssembler 
> classes and in turn calls the DAO classes. 
> 
> 
> The test case calls the SiteDelegate which internally finds the service
> and executes the service. 
> 
> The build.xml does exactly as mentioned in the documentation.
> 
> set the classpath for the cobertura.jar.
> compile the java files.
> Create instrumented classes over the compilation classes
> set the classpath for the instrumented classes
> run the testcase
> create the report.
> 
> On analysis of the report, we could find code coverage only for delegate
> class and there no coverage is been reported for other classes such
> as EJB, VOAssembler and DAO. 
> 
> 
> Kindly can you help in resolving this problem.
> 
> Thanks and Regards
> Harish
> 

RE: [Cobertura-devel] javanscc jar dependencies ?

[Czechowski, I. <Igo...@sa...>]

I came up with the two ideas.=20

First, what do you think about including other source code metrics
javancss provides in the cobertura report ?

Second I would like to be able to specify details of metrics that are
being reported, especially if the output format is XML.=20
This functionality would allow me to integrate cobertura with the
CruiseControl nightly build. Since I would be able to output the
coverage metrics for all packages without any detail about the
particular *.class file.

So the scenario would be to produce the entire html report and only the
package overview of the xml one. Then I would use transformation to
produce the html page for the cruisecontrol. I can merge the existing
xml report but I thing it's a little bit over reporting for me at the
current state.

The user would have the overview coverage on the cruisecontrol web page
and if he wants detailed coverage information then he could visit the
artifacts directory where the report would be stored.

Thanks
  Igor


-----Original Message-----
From: Mark Doliner [mailto:Mar...@sa...]=20
Sent: Wednesday, May 18, 2005 4:47 PM
To: Czechowski, Igor; Cobertura-devel
Subject: RE: [Cobertura-devel] javanscc jar dependencies ?

And it would probably be better if we didn't include the entire javancss
and ccl jars, since we're only using them to determine code complexity.
-Mark

> -----Original Message-----
> From: cob...@li...=20
> [mailto:cob...@li...] On=20
> Behalf Of Jeremy Ryan Thomerson
> Sent: Wednesday, May 18, 2005 10:22 AM
> To: Czechowski, Igor; Cobertura-devel
> Subject: Re: [SPAM-LOW] [Cobertura-devel] javanscc jar dependencies ?
>=20
> net.sourceforge.cobertura.reporting.Util relies on
> import javancss.Javancss;
> import javancss.JavancssConstants;
>=20
> for the getCCN(File, boolean) method.
>=20
> Jeremy Thomerson
>=20
>=20
> ----- Original Message -----=20
> From: "Czechowski, Igor" <Igo...@sa...>
> To: "Cobertura-devel" <cob...@li...>
> Sent: Wednesday, May 18, 2005 9:14 AM
> Subject: [SPAM-LOW] [Cobertura-devel] javanscc jar dependencies ?
>=20
>=20
> Hello,
>=20
> What's the purpose of the javanscc.jar file, since I don't see any
> dependencies on this package within the source code ?
>=20
> Thanks
>   Igor
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dick
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>=20

[Cobertura-devel] Newbie: Multiple Source Directories

[Seigel, J. <Jam...@av...>]

Hello!

=20

I am new to the list and to cobertura and have a quick question that I
couldn't seem to find a clear answer to.

=20

I am wondering if it is possible to point the reporting tool to read
from multiple source directories. For example ./src & ./test  or if you
are trying to get a larger picture of coverage for multiple frameworks
all linked into one report?

=20

Or does one have to do some heavy lifting and temporarily copy all the
source into one directory and then run the tool?=20

=20

Cheers

=20

---
James Seigel
Software Developer
Avocent Mobile Solutions
Direct: 403.355.2574
Toll Free: 866.602.2002

=20

RE: [Cobertura-devel] javanscc jar dependencies ?

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

And it would probably be better if we didn't include the entire javancss =
and ccl jars, since we're only using them to determine code complexity.
-Mark

> -----Original Message-----
> From: cob...@li...=20
> [mailto:cob...@li...] On=20
> Behalf Of Jeremy Ryan Thomerson
> Sent: Wednesday, May 18, 2005 10:22 AM
> To: Czechowski, Igor; Cobertura-devel
> Subject: Re: [SPAM-LOW] [Cobertura-devel] javanscc jar dependencies ?
>=20
> net.sourceforge.cobertura.reporting.Util relies on
> import javancss.Javancss;
> import javancss.JavancssConstants;
>=20
> for the getCCN(File, boolean) method.
>=20
> Jeremy Thomerson
>=20
>=20
> ----- Original Message -----=20
> From: "Czechowski, Igor" <Igo...@sa...>
> To: "Cobertura-devel" <cob...@li...>
> Sent: Wednesday, May 18, 2005 9:14 AM
> Subject: [SPAM-LOW] [Cobertura-devel] javanscc jar dependencies ?
>=20
>=20
> Hello,
>=20
> What's the purpose of the javanscc.jar file, since I don't see any
> dependencies on this package within the source code ?
>=20
> Thanks
>   Igor
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dick
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>=20

Re: [SPAM-LOW] [Cobertura-devel] javanscc jar dependencies ?

[Jeremy R. T. <je...@th...>]

net.sourceforge.cobertura.reporting.Util relies on
import javancss.Javancss;
import javancss.JavancssConstants;

for the getCCN(File, boolean) method.

Jeremy Thomerson


----- Original Message ----- 
From: "Czechowski, Igor" <Igo...@sa...>
To: "Cobertura-devel" <cob...@li...>
Sent: Wednesday, May 18, 2005 9:14 AM
Subject: [SPAM-LOW] [Cobertura-devel] javanscc jar dependencies ?


Hello,

What's the purpose of the javanscc.jar file, since I don't see any
dependencies on this package within the source code ?

Thanks
  Igor


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id344&op=ick
_______________________________________________
Cobertura-devel mailing list
Cob...@li...
https://lists.sourceforge.net/lists/listinfo/cobertura-devel

[Cobertura-devel] javanscc jar dependencies ?

[Czechowski, I. <Igo...@sa...>]

Hello,

What's the purpose of the javanscc.jar file, since I don't see any
dependencies on this package within the source code ?

Thanks
  Igor

RE: [Cobertura-devel] All my packages have zero coverage

[<Ala...@ba...>]

Yep, that worked. thanks

-----Original Message-----
From: Mark Doliner [mailto:Mar...@sa...]=20
Sent: 17 May 2005 20:36
To: Mcinnes, Alan: IT (LDN)
Cc: cob...@li...
Subject: RE: [Cobertura-devel] All my packages have zero coverage


A few things:

* You can do a search on your computer for files named "cobertura.ser"
This file is created when you instrument your classes, and it's SUPPOSED
to be updated by your classes when your tests are run.  However,
depending on which directory your tests are run from, your classes may
instead just create a second cobertura.ser file.  If you have 2 of these
files in different directories, then this is likely the root of your
"0%" coverage.

* I'm not sure I quite trust the "merge" task... That code is largely
unchanged from the jcoverage days, and other parts of Cobertura have had
fairly major changes.  It is in need of a good overhaul.

And looking at your output, it DOES look like you have multiple ser
files: "[junit] - java.io.FileNotFoundException:
C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\build\cobertur
a.ser (The system cannot find the file specified)"

For now I think the best thing to do is to move your cobertura.ser
before and after you run your tests.  You'll want to move the file to
wherever your test classes expect to find this file.  Yes, I know this
is a bit ugly.  Hopefully this will all be much easier to deal with in
Cobertura 1.3 (mostly due to clearer documentation).

-Mark


> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...] On=20
> Behalf Of Ala...@ba...
> Sent: Wednesday, May 11, 2005 11:26 AM
> To: cob...@li...
> Subject: [Cobertura-devel] All my packages have zero coverage
>=20
> Hi guys - just downloaded the app yesterday and it looks
> great.  Trouble
> is all my packages have 0% coverage (bar 2 which have 100).  I know we
> havent got a lot of tests yet, but we have more than that ;-)
>=20
> Anyway, I have a couple of thousand files.  I use ant so I'm not sure=20
> how to pass in the cobertura.ser file property as suggested in the=20
> faq, but I tried cobertura-merge and this didn't seem to make much
> difference.  All the files and instrumented code etc seem to get
> generated ok, and the classpath references the instrumented code
>=20
> Ive attached my ant script and a snipped version of the output after=20
> running it.
>=20
> Any suggestions greatfully received
>=20
> Thanks
> Alan
>=20
> ANT:
> <property name=3D"cobertura" value=3D"${lib}/cobertura.jar" />
> 	<property name=3D"instrumented-classes"=20
> value=3D"${basedir}/instrumented-classes" />
> 	<property name=3D"coverage-report-dir"
value=3D"${basedir}/cover-rep" />
> 	<taskdef classpath=3D"${cobertura}" resource=3D"tasks.properties" />
> 	<path id=3D"coverage.classpath">
> 			<pathelement
> location=3D"${instrumented-classes}"/>
> 		    <pathelement location=3D"${config}"/>
> 			<path refid=3D"jdk.path"/>
> 			<fileset refid=3D"external.jars"/>
> 			<pathelement location=3D"${cobertura}" />
> 		</path>
> 	<target name=3D"test-coverage" depends=3D"compile-test" >
> 		<delete quiet=3D"false" failonerror=3D"false"
> includeemptydirs=3D"true">
> 			<fileset dir=3D"${instrumented-classes}" />
> 			<fileset dir=3D"${junit.results}" />
> 			<fileset dir=3D"${coverage-report-dir}" />
> 			<fileset dir=3D"${basedir}">
> 				<include name=3D"**/cobertura.ser" />
> 			</fileset>
> 		</delete>
> 		<cobertura-instrument todir=3D"${instrumented-classes}">
> 		    <fileset dir=3D"${dest}">
> 		      <include name=3D"**/*.class"/>
> 		    </fileset>
> 		  </cobertura-instrument>
> 		<mkdir dir=3D"${junit.results}"/>
> 				<junit fork=3D"yes" haltonfailure=3D"yes"
> printsummary=3D"on">
> 					<classpath
> refid=3D"coverage.classpath"/>
> 					<formatter type=3D"brief"
> usefile=3D"false"/>
> 					<formatter type=3D"xml"/>
> 					<batchtest
> todir=3D"${junit.results}">
> 						<!-- exclude Robert's
> tipctest package from unit tests -->
> 						<fileset
> dir=3D"${instrumented-classes}" includes=3D"**/${tests}.class"
> excludes=3D"**/tipctest/*.class"/>
> 					</batchtest>
> 				</junit>
> 		<cobertura-merge>
> 		    <fileset dir=3D"${basedir}">
> 		        <include name=3D"**/cobertura.ser"/>
> 		    </fileset>
> 		</cobertura-merge>
> 		<cobertura-report srcdir=3D"${src}"
> destdir=3D"${coverage-report-dir}"/>
> 	</target>
>=20
> OUTPUT:
> Buildfile:=20
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\buil
> d\build.xm
> l
> init:
> generate:
>      [echo] Generating stubs from WSDL
> compile:
>     [javac] Compiling 56 source files to=20
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\classes
> compile-test:
> test-coverage:
>    [delete] Deleting 1827 files from=20
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\inst
> rumented-c
> lasses
>    [delete] Deleted 206 directories from=20
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\inst
> rumented-c
> lasses
>    [delete] Deleting 71 files from=20
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\test-results
>    [delete] Deleted 1 directory from=20
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\test-results
>    [delete] Deleting 1776 files from=20
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\cover-rep
>    [delete] Deleted 4 directories from=20
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\cover-rep
>    [delete] Deleting 2 files from=20
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server
> [cobertura-instrument] Cobertura 1.2
> [cobertura-instrument] Copyright (C) 2003 jcoverage ltd.=20
> [cobertura-instrument] Copyright (C) 2005 Mark Doliner=20
> <the...@us...>
> [cobertura-instrument] Cobertura is licensed under the GNU General=20
> Public License [cobertura-instrument] Cobertura comes with ABSOLUTELY=20
> NO WARRANTY [cobertura-instrument] instrumenting 2116 classes to
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\inst
> rumented-c
> lasses
> [cobertura-instrument] Instrument time: 53920ms
>     [mkdir] Created dir:
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\test-results
>     [junit] Running com.barcap.credit.cdt.CDTExampleTest
>     [junit] - loading:
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\buil
> d/cobertur
> a.ser
>     [junit] - java.io.FileNotFoundException:
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\buil
> d\cobertur
> a.ser (The system cannot find the file specified)
>     [junit] - loaded: 0 items.
>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.469
> sec
>     [junit] Testsuite: com.barcap.credit.cdt.CDTExampleTest
>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.469
> sec
>     [junit] - shutdown hook started
>     [junit] - saving:
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\buil
> d/cobertur
> a.ser
>     [junit] - saved 1 entries.
>     [junit] - saved: 1 items.
>     [junit] - shutdown hook has finished
>     [junit] Running
> com.barcap.credit.cdt.domain.client.ClientManagerServiceTest
>     [junit] - loading:
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\buil
> d/cobertur
> a.ser
>     [junit] - loaded 1 entries.
>     [junit] - loaded: 1 items.
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.375
> sec
>     [junit] Testsuite:
> com.barcap.credit.cdt.domain.client.ClientManagerServiceTest
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.375
> sec
>     [junit] ------------- Standard Output ---------------
>     [junit] ------------- ---------------- ---------------
>     [junit] - shutdown hook started
>     [junit] - saving:
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\buil
> d/cobertur
> a.ser
>     [junit] - saved 331 entries.
>     [junit] - saved: 331 items.
>     [junit] - shutdown hook has finished
>     [junit] Running
> com.barcap.credit.cdt.domain.counterparty.CounterpartyManagerS
> erviceTest
>     [junit] - loading:
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\buil
> d/cobertur
> a.ser
>     [junit] - loaded 331 entries.
>     [junit] - loaded: 331 items.
>=20
> <snip>
>   lots of junit output similar to that above & below
> </snip>
>=20
>     [junit] Running com.barcap.credit.cdt.util.xml.SimpleExtractorTest
>     [junit] - loading:=20
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\buil
> d/cobertur
> a.ser
>     [junit] - loaded 850 entries.
>     [junit] - loaded: 850 items.
>     [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.438

> sec
>     [junit] - shutdown hook started
>     [junit] - saving:=20
> C:\ClearCase\mcinnesa_credit-dev\fo_CDT_Credit\CDT\Server\buil
> d/cobertur
> a.ser
>     [junit] - saved 851 entries.
>     [junit] - saved: 851 items.
>     [junit] - shutdown hook has finished
> [cobertura-merge] Cobertura 1.2
> [cobertura-merge] Copyright (C) 2003 jcoverage ltd. [cobertura-merge]=20
> Copyright (C) 2005 Mark Doliner <the...@us...>
> [cobertura-merge] Cobertura is licensed under the GNU General Public
> License
> [cobertura-merge] Cobertura comes with ABSOLUTELY NO WARRANTY
> [cobertura-merge] Cobertura instrumentation merge tool
> [cobertura-merge] cobertura loading: cobertura.ser
> [cobertura-merge] cobertura loading: build\cobertura.ser
> [cobertura-report] Cobertura 1.2
> [cobertura-report] Copyright (C) 2003 jcoverage ltd.
> [cobertura-report] Copyright (C) 2005 Mark Doliner
> <the...@us...>
> [cobertura-report] Cobertura is licensed under the GNU General Public
> License
> [cobertura-report] Cobertura comes with ABSOLUTELY NO WARRANTY
>=20
>=20
> --------------------------------------------------------------
> ----------
> For more information about Barclays Capital, please
> visit our web site at http://www.barcap.com.
>=20
>=20
> Internet communications are not secure and therefore the Barclays
> Group does not accept legal responsibility for the contents of this=20
> message.  Although the Barclays Group operates anti-virus programmes,=20
> it does not accept responsibility for any damage whatsoever that is=20
> caused by viruses being passed.  Any views or opinions presented are=20
> solely those of the author and do not necessarily represent=20
> those of the=20
> Barclays Group.  Replies to this email may be monitored by=20
> the Barclays=20
> Group for operational or business reasons.
>=20
> --------------------------------------------------------------
> ----------
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be=20
> the first software developer in space? Enter now for the Oracle Space=20
> Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id=16281&op=3Dick
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>=20

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

[Jeremy T. <je...@th...>]

I just committed the necessary changes to accomodate "coverage for the
classes HelloWorld and HelloWorld$1 would both appear on the same HTML
page".

It also removed the map of classes maintained in ProjectData since we're
already maintaining all of our classes in individual PackageData instances.
Granted, it would've been handy to continue hanging on to ClassData
instances in ProjectData, but it would have required copy and paste logic
from PackageData determining how to aggregrate data from inner classes into
its parent class.  I really hate copy and paste wcode, so I refactored it to
avoid needing it.  However, I think the better way to refactor this in the
future is have an object whose job it is to hold on to multiple ClassData
instances, and it can be the only place that contains the aggregration
logic.  Maybe?

It's late enough for now.  Hope this was what you were looking for Mark.
Let me know if it's not.  I can back out my changes.

Jeremy Thomerson
eBay

----- Original Message -----
From: "Mark Doliner" <Mar...@sa...>
To: "Jeremy Ryan Thomerson" <je...@th...>; "Jody Brownell"
<jod...@Q1...>
Cc: <cob...@li...>; "Adam Morgan"
<ada...@Q1...>
Sent: Tuesday, May 17, 2005 1:10 PM
Subject: RE: [Cobertura-devel] How can I get involved....


No, but how about Thursday?

I was hoping to get the inner-class thing resolved before releasing 1.3, but
I think I would rather release it as-in and then make changes later.

What's wrong with inner-classes, you ask?
In 1.2 the HTML reports ignored inner-classes, and did not show them as
covered/not covered.
In CVS the HTML reports show coverage for inner-classes, but they appear in
a separate HTML page instead of being nestled in with their parent, like a
happy baby bird.
Ideally, the coverage for the classes HelloWorld and HelloWorld$1 would both
appear on the same HTML page.

In summary, CVS handles this better than 1.2 did, but it's still not
perfect.  However, if people agree that it's better to release now and
improve it later, then let's do that.

-Mark

> -----Original Message-----
> From: Jeremy Ryan Thomerson [mailto:je...@th...]
> Sent: Tuesday, May 17, 2005 4:03 PM
> To: Mark Doliner; Jody Brownell
> Cc: cob...@li...; Adam Morgan
> Subject: Re: [Cobertura-devel] How can I get involved....
>
> Do we have a proposed release date for 1.3?  It seems like we
> have some
> pretty significant changes that are awaiting a release.
>
> Jeremy Thomerson
>
> ----- Original Message -----
> From: "Mark Doliner" <Mar...@sa...>
> To: "Jody Brownell" <jod...@Q1...>
> Cc: <cob...@li...>; "Adam Morgan"
> <ada...@Q1...>
> Sent: Tuesday, May 17, 2005 2:57 PM
> 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
>
> > -----Original Message-----
> > From: Jody Brownell [mailto:jod...@Q1...]
> > 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....
> >
> > 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.
> >
> > BTW - is there anything major happening now on HEAD in cvs?
> >
> > -----Original Message-----
> > From: Mark Doliner [mailto:Mar...@sa...]
> > 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
> >
> > > -----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
> > >
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_idt12&alloc_id344&op=ick
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>
>
>


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id344&op=ick
_______________________________________________
Cobertura-devel mailing list
Cob...@li...
https://lists.sourceforge.net/lists/listinfo/cobertura-devel

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

[Mark D. <ma...@ki...>]

I guess I'll say 1.3.

Currently you need 1.4 or newer for instrumenting and reporting.  You _might_
be able to use something older for running instrumented classes.

I made a stab at supporting 1.3 a few weeks ago, but I'm having second
thoughts.  It makes the cobertura distributables gigantic, because of the need
for jakarta oro, xml jars, etc.

You can see the last attempt of a 1.3 build at
http://cobertura.sourceforge.net/buildresults/projectinfo.php?project=Cobertura-jdk1.3.1
 I'm willing to accept patches to make it work better.

-Mark

On Tue, 17 May 2005 20:54:23 -0300, Jody Brownell wrote
> 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...] 
> 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
> 
> > -----Original Message-----
> > From: Jody Brownell [mailto:jod...@Q1...] 
> > 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....
> > 
> > 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. 
> > 
> > BTW - is there anything major happening now on HEAD in cvs?
> > 
> > -----Original Message-----
> > From: Mark Doliner [mailto:Mar...@sa...] 
> > 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 
> > 
> > > -----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
> > > 
> >
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_idt12&alloc_id344&op=click
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel


--
O      O  Mark Doliner
 \     |    ma...@ki...
  \    |      www.kingant.net
"There needs to be a better word for weird."

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

RE: [Cobertura-devel] improper codecoverage report

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

Because of the way Cobertura works, it only writes the cobertura.ser =
datafile when its JVM exits.  Are you exiting Weblogic AFTER your =
HttpUnit tests are run and BEFORE you call cobertura-report?

-Mark

> -----Original Message-----
> From: cob...@li...=20
> [mailto:cob...@li...] On=20
> Behalf Of Harish Prabhakara
> Sent: Tuesday, May 17, 2005 6:34 AM
> To: cob...@li...
> Cc: Iyer, Tejas; Satyadarshi Mishra; Bothra, Naveen
> Subject: [Cobertura-devel] improper codecoverage report
>=20
> hi,
>=20
> We are trying to do a code coverage analysis for an=20
> application deployed
> under Weblogic 8.1 server. The application is been tested
> using Junit as well as HttpUnit Test Cases. While doing the=20
> code coverage
> analysis we found that the code coverage is been
> reported for those classes which has been called through Junit. Code
> coverage for those Classes which are run under Weblogic=20
> environment or under HttpUnit environment is not shown as=20
> covered. For E.g.
> Let us say that we have got a Delegate class
> which calls  a service. This service is an EJB which is been=20
> deployed in the
> Weblogic server. This Ejb in turns calls some VOAssembler=20
> classes and in turn calls the DAO classes.=20
>=20
>=20
> The test case calls the SiteDelegate which internally finds=20
> the service and
> executes the service.=20
>=20
> The build.xml does exactly as mentioned in the documentation.
>=20
> set the classpath for the cobertura.jar.
> compile the java files.
> Create instrumented classes over the compilation classes
> set the classpath for the instrumented classes
> run the testcase
> create the report.
>=20
> On analysis of the report, we could find code coverage only=20
> for delegate
> class and there no coverage is been reported for other classes such
> as EJB, VOAssembler and DAO.=20
>=20
>=20
> Kindly can you help in resolving this problem.
>=20
> Thanks and Regards
> Harish
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>=20

RE: [Cobertura-devel] How do I exclude tests from my instrumentation and reports

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

I have a feeling our ant tasks may only allow for 1 include statement =
and 1 exclude statement.  That's probably bad, and should probably be =
changed.  For now I suggest calling the cobertura-instrument task =
multiple times.  For example:
=20
<cobertura-instrument todir=3D"${cobertura.instr.dir}">
  <fileset dir=3D"${build.dir}">
    <include name=3D"com/example/whatever/Happy*.class"/>
    <exclude name=3D"**/Cactus*.class"/>
  </fileset>
</cobertura-instrument>
=20
<cobertura-instrument todir=3D"${cobertura.instr.dir}">
  <fileset dir=3D"${build.dir}">
    <include name=3D"com/example/whatever/Sneezy*.class"/>
    <exclude name=3D"**/Cactus*.class"/>
  </fileset>
</cobertura-instrument>
=20
Hopefully something like that is within reason for your particular class =
file layout...
=20
-Mark



________________________________

	From: cob...@li... =
[mailto:cob...@li...] On Behalf Of =
Hobson, Don
	Sent: Sunday, May 15, 2005 11:14 PM
	To: cob...@li...
	Subject: [Cobertura-devel] How do I exclude tests from my =
instrumentation and reports
=09
=09
	This doesn't seem to work
	=20
	 <target name=3D"cob_instr" description=3D"Instrument class files with =
cobertura.">
	  <cobertura-instrument todir=3D"${cobertura.instr.dir}">
	      <fileset dir=3D"${build.dir}">
	          <include name=3D"**/**.class"/>
	          <exclude name=3D"**/Z*Test*.class"/>
	          <exclude name=3D"**/QA*Test*.class"/>
	          <exclude name=3D"**/*JUnit*.class"/>   =20
	          <exclude name=3D"**/*Cactus*.class"/>      =20
	      </fileset>
	  </cobertura-instrument>=20
	   </target>

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

[Jeremy R. T. <je...@th...>]

I'd agree that it's better as described, and ready for release.  I'll take a
look at it this PM, too, to see if I see any easy fix.

JT

----- Original Message ----- 
From: "Mark Doliner" <Mar...@sa...>
To: "Jeremy Ryan Thomerson" <je...@th...>; "Jody Brownell"
<jod...@Q1...>
Cc: <cob...@li...>; "Adam Morgan"
<ada...@Q1...>
Sent: Tuesday, May 17, 2005 3:10 PM
Subject: RE: [Cobertura-devel] How can I get involved....


No, but how about Thursday?

I was hoping to get the inner-class thing resolved before releasing 1.3, but
I think I would rather release it as-in and then make changes later.

What's wrong with inner-classes, you ask?
In 1.2 the HTML reports ignored inner-classes, and did not show them as
covered/not covered.
In CVS the HTML reports show coverage for inner-classes, but they appear in
a separate HTML page instead of being nestled in with their parent, like a
happy baby bird.
Ideally, the coverage for the classes HelloWorld and HelloWorld$1 would both
appear on the same HTML page.

In summary, CVS handles this better than 1.2 did, but it's still not
perfect.  However, if people agree that it's better to release now and
improve it later, then let's do that.

-Mark

> -----Original Message-----
> From: Jeremy Ryan Thomerson [mailto:je...@th...]
> Sent: Tuesday, May 17, 2005 4:03 PM
> To: Mark Doliner; Jody Brownell
> Cc: cob...@li...; Adam Morgan
> Subject: Re: [Cobertura-devel] How can I get involved....
>
> Do we have a proposed release date for 1.3?  It seems like we
> have some
> pretty significant changes that are awaiting a release.
>
> Jeremy Thomerson
>
> ----- Original Message ----- 
> From: "Mark Doliner" <Mar...@sa...>
> To: "Jody Brownell" <jod...@Q1...>
> Cc: <cob...@li...>; "Adam Morgan"
> <ada...@Q1...>
> Sent: Tuesday, May 17, 2005 2:57 PM
> 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
>
> > -----Original Message-----
> > From: Jody Brownell [mailto:jod...@Q1...]
> > 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....
> >
> > 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.
> >
> > BTW - is there anything major happening now on HEAD in cvs?
> >
> > -----Original Message-----
> > From: Mark Doliner [mailto:Mar...@sa...]
> > 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
> >
> > > -----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
> > >
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_idt12&alloc_id344&op=ick
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>
>
>

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

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

No, but how about Thursday?

I was hoping to get the inner-class thing resolved before releasing 1.3, =
but I think I would rather release it as-in and then make changes later.

What's wrong with inner-classes, you ask?
In 1.2 the HTML reports ignored inner-classes, and did not show them as =
covered/not covered.
In CVS the HTML reports show coverage for inner-classes, but they appear =
in a separate HTML page instead of being nestled in with their parent, =
like a happy baby bird.
Ideally, the coverage for the classes HelloWorld and HelloWorld$1 would =
both appear on the same HTML page.

In summary, CVS handles this better than 1.2 did, but it's still not =
perfect.  However, if people agree that it's better to release now and =
improve it later, then let's do that.

-Mark=20

> -----Original Message-----
> From: Jeremy Ryan Thomerson [mailto:je...@th...]=20
> Sent: Tuesday, May 17, 2005 4:03 PM
> To: Mark Doliner; Jody Brownell
> Cc: cob...@li...; Adam Morgan
> Subject: Re: [Cobertura-devel] How can I get involved....
>=20
> Do we have a proposed release date for 1.3?  It seems like we=20
> have some
> pretty significant changes that are awaiting a release.
>=20
> Jeremy Thomerson
>=20
> ----- Original Message -----=20
> From: "Mark Doliner" <Mar...@sa...>
> To: "Jody Brownell" <jod...@Q1...>
> Cc: <cob...@li...>; "Adam Morgan"
> <ada...@Q1...>
> Sent: Tuesday, May 17, 2005 2:57 PM
> Subject: RE: [Cobertura-devel] How can I get involved....
>=20
>=20
> No, there are no major changes happening in HEAD right now. =20
> However, the
> changes between 1.2 and HEAD are pretty big--I definitely=20
> suggest developing
> against CVS HEAD rather than 1.2.
> -Mark
>=20
> > -----Original Message-----
> > From: Jody Brownell [mailto:jod...@Q1...]
> > 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....
> >
> > 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.
> >
> > BTW - is there anything major happening now on HEAD in cvs?
> >
> > -----Original Message-----
> > From: Mark Doliner [mailto:Mar...@sa...]
> > 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=20
> 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
> >
> > > -----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=20
> 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=20
> 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=20
> 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=20
> 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=20
> 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=20
> process of
> > > getting involved is to find something you're interested in
> > > fixing/improving/adding and writing a patch for it.  I=20
> 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=20
> 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=20
> 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? =20
> 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
> > >
> >
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dick
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>=20
>=20
>=20
>=20

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

[Jeremy R. T. <je...@th...>]

Do we have a proposed release date for 1.3?  It seems like we have some
pretty significant changes that are awaiting a release.

Jeremy Thomerson

----- Original Message ----- 
From: "Mark Doliner" <Mar...@sa...>
To: "Jody Brownell" <jod...@Q1...>
Cc: <cob...@li...>; "Adam Morgan"
<ada...@Q1...>
Sent: Tuesday, May 17, 2005 2:57 PM
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

> -----Original Message-----
> From: Jody Brownell [mailto:jod...@Q1...]
> 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....
>
> 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.
>
> BTW - is there anything major happening now on HEAD in cvs?
>
> -----Original Message-----
> From: Mark Doliner [mailto:Mar...@sa...]
> 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
>
> > -----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
> >
>


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id344&op=ick
_______________________________________________
Cobertura-devel mailing list
Cob...@li...
https://lists.sourceforge.net/lists/listinfo/cobertura-devel

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

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

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

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

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
>