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

RE: [Cobertura-devel] Add TODO list to the CVS

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

I'm not completely against having a TODO list in CVS... But I think in t=
his case it would just duplicate the information in the bug and RFE trac=
kers.  If those two trackers become too cluttered to be able to determin=
e what should be done then I would be willing to add the file to CVS.  F=
or now I think Cobertura is small enough that it isn't necessary, and I'=
d rather avoid having to update lists in 2 places when making changes.

Future of Cobertura... No, I don't really see any big changes on the hor=
izon.  I want to split the net.sourceforge.cobertura.coverage package in=
to a net.sourceforge.cobertura.coveragedata package and a net.sourceforg=
e.cobertura.instrument package.  The former will be responsible for read=
ing, writing and storing the data itself.  The latter will be responsibl=
e for modifying the bytecode.  In the process I'd like to fix how the lo=
ading/storing of the cobertura.ser file is done.  This should take care =
of the problems related to cobertura.ser only being written when the JVM=
 exits (and needed to shut down an application server to get access to t=
he data).  The changes will also hopefully make things more testable, an=
d allow the ant tasks to specify the filename of the coverage data.

-Mark 

> -----Original Message-----
> From: cob...@li... 
> [mailto:cob...@li...] On 
> Behalf Of Grzegorz Lukasik
> Sent: Friday, April 08, 2005 10:42 AM
> To: cob...@li...
> Subject: [Cobertura-devel] Add TODO list to the CVS
> 
> I think TODO list should be added to the CVS repository. This list
> should indicate what things are needed, and if are needed does anyone
> work on it. Although there are bug and RFE lists, they do not describe
> what is really important and what should we focus on.
> 
> I attach TODO file as I see it.
> 
> I have related question. How do you see the future of Cobertura? Are
> there any big changes on the horizon?
> 
> Grzegorz Lukasik
> 

[Cobertura-devel] Add TODO list to the CVS

[Grzegorz L. <ha...@gm...>]

I think TODO list should be added to the CVS repository. This list
should indicate what things are needed, and if are needed does anyone
work on it. Although there are bug and RFE lists, they do not describe
what is really important and what should we focus on.

I attach TODO file as I see it.

I have related question. How do you see the future of Cobertura? Are
there any big changes on the horizon?

Grzegorz Lukasik

RE: [Cobertura-devel] Report Question

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

The log4j properties file is really the only way to change the level of =
information printed.  I'm suppose you could run your code in a debugger, =
but I'm not sure if that would accomplish very much.
=20
About the syncrhonized block thing... that's very possible, I'll try to =
take a look at that sometime.
-Mark
=20


________________________________

	From: Martha Yanez [mailto:my...@us...]=20
	Sent: Thursday, April 07, 2005 10:34 AM
	To: Mark Doliner
	Cc: cob...@li...
	Subject: RE: [Cobertura-devel] Report Question
=09
=09

	Hi Mark,=20
	I'll try reproducing the the finally error but in case I'm not =
sucessful are there any traces that I can take with my current code =
(Grzegorz indicated the debug option in log4j properties file but I =
don't see much recorded when I run test).=20
=09
	I've noticed the end bracket being counted as zero in almost every =
synchronized block that I've seen and almost all of them are not at the =
end of a method. I think there is a problem with that particular key =
word/block=20
=09
	Thanks=20
=09
	Martha Yanez
	(919) 224-1320 / 8-687-1320
	New Notes id: Martha Yanez/Raleigh/IBM
	my...@us...
=09
=09
=09
=09
=09
"Mark Doliner" <Mar...@sa...>=20
Sent by: cob...@li...=20

04/07/2005 09:27 AM=20

To
Martha Yanez/Raleigh/IBM@IBMUS, <cob...@li...>=20
cc
Subject
RE: [Cobertura-devel] Report Question

=09




	> Hello all=20
	> I've gotten reports to run (many thanks to Grzegorz) and am slowly =
starting to analyze some results most of which look accurate.=20
	> However I'm seeing some odd items like the  following:=20
	>=20
	>  353            finally=20
	>  354            {=20
	>  355  0             if (allOK)=20
	>  356                {    // Life is WONDERFUL!!!  Issue MEM started  =
message=20
	>  357  3                 status =3D Status.STATUS_RUNNING;=20
	>  358                     =
xLogger.message(IRecordType.TYPE_INFO,CLASSNAME,methodName,"DYKME9016I");=
=20
	>  359                }=20
	>  360                else=20
	>  361                {=20
	>  362  0                 status =3D Status.STATUS_FAILED;       // =
very important to set=20
	>=20
	> Line 355 is highlited in pink and show zero coverage yet it was =
definitely executed as indicated by line 357 and the appearence of the =
message=20
	> on my console.=20
=09
	That definitely shouldn't be happening...  If you're able to reproduce =
this in a small, hello world-like program then it would be great if you =
could file a bug report about it.
=09
	> Another one is:=20
	>  246  3          synchronized(this)=20
	>  247             {=20
	>  248  3             if (status =3D=3D STATUS_STARTING)=20
	>  249                {=20
	>  250  3                  status =3D STATUS_STEADY_STATE;=20
	>  251  3                  threadSuspended =3D false;=20
	>  252  3                  notify();=20
	>  253                }=20
	>  254  0         }=20
	>=20
	> Line 254 which is simply the closing bracket of a block that has been =
executed is showing a zero count.=20
=09
	For this one, line 254 should probably not be considered a line of =
code.  Is this block at the end of a method?  At the end of methods that =
return void, I belive a "return" instruction is added in the bytecode, =
even if one is not explictly stated in the code.  Maybe Cobertura is =
looking at line 254 as this implicit return instruction?
=09
	-Mark
=09
=09
	-------------------------------------------------------
	SF email is sponsored by - The IT Product Guide
	Read honest & candid reviews on hundreds of IT Products from real =
users.
	Discover which products truly live up to the hype. Start reading now.
	http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick
	_______________________________________________
	Cobertura-devel mailing list
	Cob...@li...
	https://lists.sourceforge.net/lists/listinfo/cobertura-devel
=09
=09

RE: [Cobertura-devel] Report Question

[Martha Y. <my...@us...>]

Hi Mark,
I'll try reproducing the the finally error but in case I'm not sucessful=20
are there any traces that I can take with my current code (Grzegorz=20
indicated the debug option in log4j properties file but I don't see much=20
recorded when I run test).

I've noticed the end bracket being counted as zero in almost every=20
synchronized block that I've seen and almost all of them are not at the=20
end of a method. I think there is a problem with that particular key=20
word/block

Thanks

Martha Yanez
(919) 224-1320 / 8-687-1320
New Notes id: Martha Yanez/Raleigh/IBM
my...@us...





"Mark Doliner" <Mar...@sa...>=20
Sent by: cob...@li...
04/07/2005 09:27 AM

To
Martha Yanez/Raleigh/IBM@IBMUS, <cob...@li...>
cc

Subject
RE: [Cobertura-devel] Report Question






> Hello all=20
> I've gotten reports to run (many thanks to Grzegorz) and am slowly=20
starting to analyze some results most of which look accurate.=20
> However I'm seeing some odd items like the  following:=20
>=20
>  353            finally=20
>  354            {=20
>  355  0             if (allOK)=20
>  356                {    // Life is WONDERFUL!!!  Issue MEM started=20
message=20
>  357  3                 status =3D Status.STATUS=5FRUNNING;=20
>  358=20
xLogger.message(IRecordType.TYPE=5FINFO,CLASSNAME,methodName,"DYKME9016I");=
=20
>  359                }=20
>  360                else=20
>  361                {=20
>  362  0                 status =3D Status.STATUS=5FFAILED;       // very =

important to set=20
>=20
> Line 355 is highlited in pink and show zero coverage yet it was=20
definitely executed as indicated by line 357 and the appearence of the=20
message=20
> on my console.=20

That definitely shouldn't be happening...  If you're able to reproduce=20
this in a small, hello world-like program then it would be great if you=20
could file a bug report about it.

> Another one is:=20
>  246  3          synchronized(this)=20
>  247             {=20
>  248  3             if (status =3D=3D STATUS=5FSTARTING)=20
>  249                {=20
>  250  3                  status =3D STATUS=5FSTEADY=5FSTATE;=20
>  251  3                  threadSuspended =3D false;=20
>  252  3                  notify();=20
>  253                }=20
>  254  0         }=20
>=20
> Line 254 which is simply the closing bracket of a block that has been=20
executed is showing a zero count.=20

For this one, line 254 should probably not be considered a line of code.=20
Is this block at the end of a method?  At the end of methods that return=20
void, I belive a "return" instruction is added in the bytecode, even if=20
one is not explictly stated in the code.  Maybe Cobertura is looking at=20
line 254 as this implicit return instruction?

-Mark


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad=5Fide95&alloc=5Fid=14396&op=3Dclick
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Cobertura-devel mailing list
Cob...@li...
https://lists.sourceforge.net/lists/listinfo/cobertura-devel

RE: [Cobertura-devel] Report Question

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

> Hello all=20
> I've gotten reports to run (many thanks to Grzegorz) and am slowly =
starting to analyze some results most of which look accurate.=20
> However I'm seeing some odd items like the  following:=20
>=20
>  353            finally=20
>  354            {=20
>  355  0             if (allOK)=20
>  356                {    // Life is WONDERFUL!!!  Issue MEM started  =
message=20
>  357  3                 status =3D Status.STATUS_RUNNING;=20
>  358                     =
xLogger.message(IRecordType.TYPE_INFO,CLASSNAME,methodName,"DYKME9016I");=
=20
>  359                }=20
>  360                else=20
>  361                {=20
>  362  0                 status =3D Status.STATUS_FAILED;       // very =
important to set=20
>=20
> Line 355 is highlited in pink and show zero coverage yet it was =
definitely executed as indicated by line 357 and the appearence of the =
message=20
> on my console.=20

That definitely shouldn't be happening...  If you're able to reproduce =
this in a small, hello world-like program then it would be great if you =
could file a bug report about it.

> Another one is:=20
>  246  3          synchronized(this)=20
>  247             {=20
>  248  3             if (status =3D=3D STATUS_STARTING)=20
>  249                {=20
>  250  3                  status =3D STATUS_STEADY_STATE;=20
>  251  3                  threadSuspended =3D false;=20
>  252  3                  notify();=20
>  253                }=20
>  254  0         }=20
>=20
> Line 254 which is simply the closing bracket of a block that has been =
executed is showing a zero count.=20

For this one, line 254 should probably not be considered a line of code. =
 Is this block at the end of a method?  At the end of methods that =
return void, I belive a "return" instruction is added in the bytecode, =
even if one is not explictly stated in the code.  Maybe Cobertura is =
looking at line 254 as this implicit return instruction?

-Mark

[Cobertura-devel] Report Question

[Martha Y. <my...@us...>]

Hello all 
I've gotten reports to run (many thanks to Grzegorz) and am slowly 
starting to analyze some results most of which look accurate.
However I'm seeing some odd items like the  following:

 353            finally
 354            {
 355  0             if (allOK) 
 356                {    // Life is WONDERFUL!!!  Issue MEM started 
message
 357  3                 status = Status.STATUS_RUNNING;
 358     
xLogger.message(IRecordType.TYPE_INFO,CLASSNAME,methodName,"DYKME9016I");
 359                }
 360                else
 361                {
 362  0                 status = Status.STATUS_FAILED;       // very 
important to set 

Line 355 is highlited in pink and show zero coverage yet it was definitely 
executed as indicated by line 357 and the appearence of the message
on my console.

Another one is:
 246  3          synchronized(this) 
 247             {
 248  3             if (status == STATUS_STARTING)
 249                {
 250  3                  status = STATUS_STEADY_STATE;
 251  3                  threadSuspended = false;
 252  3                  notify();
 253                }
 254  0         }

Line 254 which is simply the closing bracket of a block that has been 
executed is showing a zero count.

These look wrong to me or am I missing something in how the coverage is 
determined?  Thanks
 
Martha Yanez
(919) 224-1320 / 8-687-1320
New Notes id: Martha Yanez/Raleigh/IBM
my...@us...

Re: [Cobertura-devel] Having problems generating report, possible instrumentation problem as well

[Grzegorz L. <ha...@gm...>]

I attach Cobertura compiled from the newest sources from CVS - it
should fix your problems.

Thanks for your help!

Greetings
Grzegorz Lukasik

Re: [Cobertura-devel] Having problems generating report, possible instrumentation problem as well

[Grzegorz L. <ha...@gm...>]

Hi,

Yes it seems that computing complexity on non source files takes so
long for you.
New release will fix it.

Greetings
Grzegorz Lukasik

On Apr 4, 2005 10:00 PM, Martha Yanez <my...@us...> wrote:
>  
> Hi, 
> The new jar hangs just like the original jar.... here is the output from the
> run. It basically get to write that within the first minute or so and then
> nothing more till I kill the process. The stuff I pruned out of the source
> tree would definitely have some non-java files (alot of db2 related files)
> so skipping those may have made the difference 
>  
>  
>  
> When will version 1.3 be released? Thanks 
>  
> 
>  Martha Yanez
>  (919) 224-1320 / 8-687-1320
>  New Notes id: Martha Yanez/Raleigh/IBM
>  my...@us...
>  
>  
>  
>  
>  
>  Grzegorz Lukasik <ha...@gm...> 
> 
> 04/04/2005 03:13 PM 
>  
> Please respond to
>  Grzegorz Lukasik 
>  
>  
> To Martha Yanez/Raleigh/IBM@IBMUS 
>  
> cc cob...@li... 
>  
> Subject Re: [Cobertura-devel] Having problems generating report, possible
> instrumentation problem as well 
>  
>  
>  
>  
>  
> ***********************
>  Warning: Your file, cobertura.jar, contains more than 32 files after
> decompression and cannot be scanned.
> 
>  ***********************
>  
>  
>  Hi
>  
>  Ok, the file that i sent you contained not only debug lines but also
>  changes that will be released in version 1.3 of Cobertura - It was
>  compiled from fresh CVS copy. Two important changes that may affected
>  you are:
>  
>  * Do not compute complexity for all files, just for *.java files - can
>  reduce time of execution if there are many non source files
>  * Do not compute complexity of files in some special cases  -
>  Cobertura can hang up in some very rare situtations -  but then it
>  should show 0% CPU use
>  
>  I guess it is the first option.
>  
>  OK, I attached version of cobertura.jar with added just logging lines
>  with comparision to 1.2 and nothing more - could you once more check
>  it ;)
>  
>  Grzegorz Lukasik
>  
>  
>  On Apr 4, 2005 8:19 PM, Martha Yanez <my...@us...> wrote:
>  >  
>  > Hello again, 
>  > Some more results: 
>  > If I run your new jar  against my unpruned source tree, it completes in
>  > roughly 2-3  minutes and here is debug output. ( So sheer size is not
>  > problem) 
>  >  
>  >  
>  > If I run original jar with debug set in log4j.properties, it still hangs
> --
>  > have waited close to 10 minutes observing 100% CPU utilization until I
> kill
>  > the process. Here is the debug output (not very interesting) 
>  > DEBUG  main, format is html 
>  > DEBUG  main, serializationFile is
>  > c:\buildSLM\build-dir\coberturaTest\cobertura.ser 
>  > DEBUG  main, outputDir is
>  > c:\buildSLM\build-dir\coberturaTest\r3 
>  > DEBUG  main, sourceDir is c:\buildSLM\build-dir\src 
>  >  
>  >  
>  > If I run original jar against a pruned source tree ( still large (over a
>  > thousand files) , report completes in roughly 2-3 minutes!  I suspect I
>  > pruned something that is causing an endless loop but it doesn't happen
> with
>  > the modified jar you sent me. I'm perplexed on how to pinpoint without
>  > selectively dropping in pruned items and rerunning which can be time
>  > consuming. Were there any differences in actual code beside debug
> statements
>  > in the jar you sent me and version 1.2 of cobertura ( i downloaded last
>  > Thursday)? 
>  >  
>  >  
>  > I have another question regarding report output in comparsion to
> JCoverage. 
>  > When instrumenting basically the same set of files and running same
> testcase
>  > I looked at output of cobertura and jcoverage. the %line coverage is
> nearly
>  > the same in the package overview but the %branch is quite different in
> some
>  > cases.  I randomly picked one (SimpleThread) that had quite a large
>  > difference (Jcoverage indicated 66 % and cobertua indicates 0%) and
> enclosed
>  > those htmls. Frankly I was not altogether sure of how Jcoverage
> calculated
>  > branch coverage and what that number meant against line coverage but I've
>  > been focused on getting tool to work and saving analysis for later.
> (website
>  > doc was useless in describing branch coverage).  I now see cobertura is
>  > generally lower and really would like to understand how determined and
> which
>  > number is more useful to focus on (% line or % branch - I suspect %
> branch).
>  >  The src output highlites shows only the lines not touched - correct?  
>  > There is no visual indication of branching coverage I believe. 
>  >  
>  >  
>  > Thanks again for your support - I was flying blind with JCoverage and
> it's
>  > great to be able to get some basic questions addressed! 
>  >  
>  >  
>  > 
>  >  Martha Yanez
>  >  (919) 224-1320 / 8-687-1320
>  >  New Notes id: Martha Yanez/Raleigh/IBM
>  >  my...@us...
>  >  
>  >  
>  >  
>  >  
>  >  
>  >  Grzegorz Lukasik <ha...@gm...> 
>  > 
>  > 04/04/2005 12:32 PM 
>  >  
>  >  
>  > Please respond to
>  >  Grzegorz Lukasik 
>  >  
>  >  
>  > To Martha Yanez/Raleigh/IBM@IBMUS 
>  >  
>  > cc cob...@li... 
>  >  
>  > Subject Re: [Cobertura-devel] Having problems generating report, possible
>  > instrumentation problem as well 
>  >  
>  >  
>  >  
>  >  
>  >  
>  > ***********************
>  >  Warning: Your file, modified.jar, contains more than 32 files after
>  > decompression and cannot be scanned.
>  >  ***********************
>  >  
>  >  
>  >  Hi
>  >  
>  >  Sory for bad file.
>  >  I have attached modified version of modified.jar.
>  >  
>  >  Please send mi info if there are still some problems with it.
>  >  
>  >  Grzegorz Lukasik 
>  >  
>  >  On Apr 4, 2005 5:14 PM, Martha Yanez <my...@us...> wrote:
>  >  >  
>  >  > Hi Grzegorz 
>  >  > First of all... thanks for your speedy reply. I think I have an
>  > interesting
>  >  > clue to the problem - the size of the source directory is the key. My
>  >  > original product source directory is very big  (169 MB - 10, 172
> files). 
>  >  > Even I was using the little test program (DateUtil) I had placed the
>  > source
>  >  > on my root build directory which is even bigger. When I place the
> source,
>  >  > and ser file in a unique directory, the report command works
> instantly.  
>  >  > I tried this after trying to point the source to an empty directory as
>  > you
>  >  > asked. The report command still hangs but I noticed that task's
> manager's
>  >  > performance was minimal ( not 100% as I observed earlier). That's what
>  > led
>  >  > me to suspect size of directory. 
>  >  > When I tried the modified jar, it hangs in all cases with an Exception
> in
>  >  > thread "main" java.lang.NoClassDefFoundError:
>  >  > net/sourceforge/cobertura/reporting/Util$1 but that
> is
>  >  > pointing to the following code: 
>  >  >  
>  >  >    private static Vector getListOfFiles(File file, boolean recursive) 
>  >  >         { 
>  >  >                 Vector ret = new Vector(); 
>  >  >                 logger.debug( "getListOfFiles file=" + file+ "
>  >  > recursive="+recursive); 
>  >  >  
>  >  >                 if (file.isFile()) 
>  >  >                 { 
>  >  >                         ret.add(file.getAbsolutePath()); 
>  >  >                 } 
>  >  >                 else if (file.isDirectory()) 
>  >  >                 { 
>  >  >                         File[] files = file.listFiles(new FileFilter()
>  >  >                         { 
>  >  >                                 public boolean accept(File pathname) 
>  >  >                                 { 
>  >  >                                         return pathname.isDirectory() 
>  >  >                                                         ||
>  >  > pathname.getAbsolutePath().endsWith(".java"); 
>  >  >                                 } 
>  >  >                         }); 
>  >  >  
>  >  >                         for (int i = 0; i < files.length; i++) 
>  >  >                         { 
>  >  >                                 if (recursive) 
>  >  >                                 { 
>  >  >                                        
>  > ret.addAll(getListOfFiles(files[i],
>  >  > true)); 
>  >  >                                 } 
>  >  >                                 else 
>  >  >                                 { 
>  >  >                                         if (files[i].isFile()) 
>  >  >                                         { 
>  >  >                                                
>  >  > ret.add(files[i].getAbsolutePath()); 
>  >  >                                         } 
>  >  >                                 } 
>  >  >                         } 
>  >  >                 } 
>  >  >  
>  >  >  
>  >  > I can see how the size of the directory would overpower this loop.
> What
>  > is
>  >  > curious is that I used the same directory for my JCoverage reporting
> and
>  > had
>  >  > no problems in this area. Reporting would not be instant but would
>  > finished
>  >  > in a few minutes .  My problems with JCoverage were more in the area
> of
>  >  > random exceptions as I had my product running with major sections
>  >  > instrumented (about 900 classes). When I instrumented in smaller
> batches
>  >  > (200 classes or less), I could get viable ser files and generate
> reports.
>  >  > Here is the output from the modified jar but again the exception
>  > terminated
>  >  > each before it could complete so I don't think this will be useful 
>  >  >  
>  >  >  
>  >  >  
>  >  > I just wanted to get this info to you quickly but I would like to run
>  >  > another test after pruning down my source directory to just the files
> I
>  > need
>  >  > to instrument. This may take a while and since the modified jar is
> having
>  >  > problems I was going to just run the original jar with the debug
> options
>  > you
>  >  > mentioned.  I'll let you know results but it may take a while since I
>  > have
>  >  > to head to some meetings now. 
>  >  >  
>  >  > Thanks 
>  >  >  
>  >  >  
>  >  > 
>  >  >  Martha Yanez
>  >  >  (919) 224-1320 / 8-687-1320
>  >  >  New Notes id: Martha Yanez/Raleigh/IBM
>  >  >  my...@us...
>  >  >  
>  >  >  
>  >  >  
>  >  >  
>  >  >  
>  >  >  Grzegorz Lukasik <ha...@gm...> 
>  >  > 
>  >  > 04/02/2005 11:29 AM 
>  >  >  
>  >  > Please respond to
>  >  >  Grzegorz Lukasik 
>  >  >  
>  >  >  
>  >  > To Martha Yanez/Raleigh/IBM@IBMUS 
>  >  >  
>  >  > cc cob...@li... 
>  >  >  
>  >  > Subject Re: [Cobertura-devel] Having problems generating report,
> possible
>  >  > instrumentation problem as well 
>  >  >  
>  >  >  
>  >  >  
>  >  >  
>  >  >  
>  >  > ***********************
>  >  >  Warning: Your file, modified.jar, contains more than 32 files after
>  >  > decompression and cannot be scanned.
>  >  >  ***********************
>  >  > 
>  >  >  
>  >  >  
>  >  >  Hi
>  >  >  
>  >  >  I tried it the way you specified and it worked for me. Yours
>  >  >  cobertura.ser looks ok. It seems that there is something wrong with
>  >  >  reporting process - but i cannot reproduce behaviour you experienced.
>  >  >  I will try to help you - and us to find a bug.
>  >  >  
>  >  >  First
>  >  >  Could you create some empty directory and point cobertura to look for
>  >  >  sources there (using option -s) when using report generation?
>  >  >  
>  >  >  Second could you use attached jar (modified.jar) instead of
>  >  >  cobertura.jar? I modified two files (HTMLReport and Util) to show
> much
>  >  >  more information about things that happen. I also set there reporting
>  >  >  level to debug. Could you run reporting of your simple case and send
>  >  >  as what was logged? Modified files are attached.
>  >  >  
>  >  >  To increase the number of log messages in normal cobertura
>  >  >  distribution file you will have to edit cobertura.jar and in file
>  >  >  log4j.properties change debug level from WARN to DEBUG.
>  >  >  
>  >  >  Here is SourceForge archive for list cobertura-devel:
>  >  >
>  >
> https://sourceforge.net/mailarchive/forum.php?forum_id=44317
>  >  >  
>  >  >  Thanks for comprehensive description!
>  >  >  
>  >  >  Greetings
>  >  >  Grzegorz Lukasik 
>  >  >  
>  >  >  On Apr 2, 2005 1:17 AM, Martha Yanez <my...@us...> wrote:
>  >  >  >  
>  >  >  > 
>  >  >  >  Hi, 
>  >  >  > I'm trying to run cobertura with a tiny test program and having
>  > problem
>  >  >  > generating a report. 
>  >  >  > This is program, class files and ser output   . 
>  >  >  >  
>  >  >  > Cobertura.jar is in my classpath and I run following reporting
> command
>  >  > after
>  >  >  > executing DateUtil. 
>  >  >  >  
>  >  >  > C:\buildSLM>java
>  >  > net.sourceforge.cobertura.reporting.Main 
>  >  >  > -o c:\buildSLM\build-dir\r2 -i c:\buildSLM\cobertura.ser -s
>  > c:\buildSLM
>  >  > -f
>  >  >  > html 
>  >  >  >  
>  >  >  > The report command never terminates and my machine hits 100%
>  > processing
>  >  > when
>  >  >  > viewed under Task Manager 
>  >  >  > Some report files (index.html, frame-classes.html,
> frame-classes-.html
>  >  > (not
>  >  >  > a dup), frame-packages.html and frame-summary.html)  are generated
>  > very
>  >  >  > quickly at the start and then nothing.   
>  >  >  >  
>  >  >  >  
>  >  >  > I started this small test case because I suspect I may have an
>  >  >  > instrumentation problem. I tried instrumenting some of my product
>  > files
>  >  >  > (switching from the Jcoverage statements to the Cobertura ones
>  > Grzegorz
>  >  > was
>  >  >  > kind enough to send me this morning). It seems to go fine but when
> I
>  > ran
>  >  > the
>  >  >  > product I did not see the Cobertura.ser file being updated.  Since
> my
>  >  >  > product environment is a bit complex, I wanted to make sure I could
>  > get
>  >  > the
>  >  >  > simple test case working first and the little bit the report shows
>  > does
>  >  > seem
>  >  >  > like the test case ran (80%) but then the report problem comes in.
> If
>  > I
>  >  > try
>  >  >  > the ser file from my product instrumentation, the same thing
> happens
>  > (no
>  >  >  > termination - showing 0 coverage) 
>  >  >  >  
>  >  >  > Any help appreciated since I have limited time to get this
> working...
>  >  > also
>  >  >  > is there a debug or additional logging function I can turn on for
> more
>  >  > info
>  >  >  > on program execution?   
>  >  >  > One last thing... is there a way to see past mailing list entries?
> I'm
>  >  > now
>  >  >  > getting new updates but can't find past questions and hate to
> bother
>  > you
>  >  >  > asking something again that's been answered.   Thanks! 
>  >  >  > 
>  >  >  >  Martha Yanez
>  >  >  >  (919) 224-1320 / 8-687-1320
>  >  >  >  New Notes id: Martha Yanez/Raleigh/IBM
>  >  >  >  my...@us...
>  >  >  >  
>  >  >  >  
>  >  >  >
>  >  >  
>  >  >  [attachment "modified.jar" deleted by Martha Yanez/Raleigh/IBM]
>  > [attachment
>  >  > "log4j.properties" deleted by Martha Yanez/Raleigh/IBM] [attachment
>  >  > "Util.java" deleted by Martha Yanez/Raleigh/IBM] [attachment
>  >  > "HTMLReport.java" deleted by Martha Yanez/Raleigh/IBM] 
>  >  >  
>  >  >
>  >  
>  >  [attachment "modified.jar" deleted by Martha Yanez/Raleigh/IBM] 
>  >  
>  >
>  
>  [attachment "cobertura.jar" deleted by Martha Yanez/Raleigh/IBM] 
>  
>

Re: [Cobertura-devel] Having problems generating report, possible instrumentation problem as well

[Grzegorz L. <ha...@gm...>]

Hi

Ok, the file that i sent you contained not only debug lines but also
changes that will be released in version 1.3 of Cobertura - It was
compiled from fresh CVS copy. Two important changes that may affected
you are:

* Do not compute complexity for all files, just for *.java files - can
reduce time of execution if there are many non source files
* Do not compute complexity of files in some special cases  -
Cobertura can hang up in some very rare situtations -  but then it
should show 0% CPU use

I guess it is the first option.

OK, I attached version of cobertura.jar with added just logging lines
with comparision to 1.2 and nothing more - could you once more check
it ;)

Grzegorz Lukasik


On Apr 4, 2005 8:19 PM, Martha Yanez <my...@us...> wrote:
>  
> Hello again, 
> Some more results: 
> If I run your new jar  against my unpruned source tree, it completes in
> roughly 2-3  minutes and here is debug output. ( So sheer size is not
> problem) 
>  
>  
> If I run original jar with debug set in log4j.properties, it still hangs --
> have waited close to 10 minutes observing 100% CPU utilization until I kill
> the process. Here is the debug output (not very interesting) 
> DEBUG  main, format is html 
> DEBUG  main, serializationFile is
> c:\buildSLM\build-dir\coberturaTest\cobertura.ser 
> DEBUG  main, outputDir is
> c:\buildSLM\build-dir\coberturaTest\r3 
> DEBUG  main, sourceDir is c:\buildSLM\build-dir\src 
>  
>  
> If I run original jar against a pruned source tree ( still large (over a
> thousand files) , report completes in roughly 2-3 minutes!  I suspect I
> pruned something that is causing an endless loop but it doesn't happen with
> the modified jar you sent me. I'm perplexed on how to pinpoint without
> selectively dropping in pruned items and rerunning which can be time
> consuming. Were there any differences in actual code beside debug statements
> in the jar you sent me and version 1.2 of cobertura ( i downloaded last
> Thursday)? 
>  
>  
> I have another question regarding report output in comparsion to JCoverage. 
> When instrumenting basically the same set of files and running same testcase
> I looked at output of cobertura and jcoverage. the %line coverage is nearly
> the same in the package overview but the %branch is quite different in some
> cases.  I randomly picked one (SimpleThread) that had quite a large
> difference (Jcoverage indicated 66 % and cobertua indicates 0%) and enclosed
> those htmls. Frankly I was not altogether sure of how Jcoverage calculated
> branch coverage and what that number meant against line coverage but I've
> been focused on getting tool to work and saving analysis for later. (website
> doc was useless in describing branch coverage).  I now see cobertura is
> generally lower and really would like to understand how determined and which
> number is more useful to focus on (% line or % branch - I suspect % branch).
>  The src output highlites shows only the lines not touched - correct?  
> There is no visual indication of branching coverage I believe. 
>  
>  
> Thanks again for your support - I was flying blind with JCoverage and it's
> great to be able to get some basic questions addressed! 
>  
>  
> 
>  Martha Yanez
>  (919) 224-1320 / 8-687-1320
>  New Notes id: Martha Yanez/Raleigh/IBM
>  my...@us...
>  
>  
>  
>  
>  
>  Grzegorz Lukasik <ha...@gm...> 
> 
> 04/04/2005 12:32 PM 
>  
>  
> Please respond to
>  Grzegorz Lukasik 
>  
>  
> To Martha Yanez/Raleigh/IBM@IBMUS 
>  
> cc cob...@li... 
>  
> Subject Re: [Cobertura-devel] Having problems generating report, possible
> instrumentation problem as well 
>  
>  
>  
>  
>  
> ***********************
>  Warning: Your file, modified.jar, contains more than 32 files after
> decompression and cannot be scanned.
>  ***********************
>  
>  
>  Hi
>  
>  Sory for bad file.
>  I have attached modified version of modified.jar.
>  
>  Please send mi info if there are still some problems with it.
>  
>  Grzegorz Lukasik 
>  
>  On Apr 4, 2005 5:14 PM, Martha Yanez <my...@us...> wrote:
>  >  
>  > Hi Grzegorz 
>  > First of all... thanks for your speedy reply. I think I have an
> interesting
>  > clue to the problem - the size of the source directory is the key. My
>  > original product source directory is very big  (169 MB - 10, 172 files). 
>  > Even I was using the little test program (DateUtil) I had placed the
> source
>  > on my root build directory which is even bigger. When I place the source,
>  > and ser file in a unique directory, the report command works instantly.  
>  > I tried this after trying to point the source to an empty directory as
> you
>  > asked. The report command still hangs but I noticed that task's manager's
>  > performance was minimal ( not 100% as I observed earlier). That's what
> led
>  > me to suspect size of directory. 
>  > When I tried the modified jar, it hangs in all cases with an Exception in
>  > thread "main" java.lang.NoClassDefFoundError:
>  > net/sourceforge/cobertura/reporting/Util$1 but that is
>  > pointing to the following code: 
>  >  
>  >    private static Vector getListOfFiles(File file, boolean recursive) 
>  >         { 
>  >                 Vector ret = new Vector(); 
>  >                 logger.debug( "getListOfFiles file=" + file+ "
>  > recursive="+recursive); 
>  >  
>  >                 if (file.isFile()) 
>  >                 { 
>  >                         ret.add(file.getAbsolutePath()); 
>  >                 } 
>  >                 else if (file.isDirectory()) 
>  >                 { 
>  >                         File[] files = file.listFiles(new FileFilter() 
>  >                         { 
>  >                                 public boolean accept(File pathname) 
>  >                                 { 
>  >                                         return pathname.isDirectory() 
>  >                                                         ||
>  > pathname.getAbsolutePath().endsWith(".java"); 
>  >                                 } 
>  >                         }); 
>  >  
>  >                         for (int i = 0; i < files.length; i++) 
>  >                         { 
>  >                                 if (recursive) 
>  >                                 { 
>  >                                        
> ret.addAll(getListOfFiles(files[i],
>  > true)); 
>  >                                 } 
>  >                                 else 
>  >                                 { 
>  >                                         if (files[i].isFile()) 
>  >                                         { 
>  >                                                
>  > ret.add(files[i].getAbsolutePath()); 
>  >                                         } 
>  >                                 } 
>  >                         } 
>  >                 } 
>  >  
>  >  
>  > I can see how the size of the directory would overpower this loop. What
> is
>  > curious is that I used the same directory for my JCoverage reporting and
> had
>  > no problems in this area. Reporting would not be instant but would
> finished
>  > in a few minutes .  My problems with JCoverage were more in the area of
>  > random exceptions as I had my product running with major sections
>  > instrumented (about 900 classes). When I instrumented in smaller batches
>  > (200 classes or less), I could get viable ser files and generate reports.
>  > Here is the output from the modified jar but again the exception
> terminated
>  > each before it could complete so I don't think this will be useful 
>  >  
>  >  
>  >  
>  > I just wanted to get this info to you quickly but I would like to run
>  > another test after pruning down my source directory to just the files I
> need
>  > to instrument. This may take a while and since the modified jar is having
>  > problems I was going to just run the original jar with the debug options
> you
>  > mentioned.  I'll let you know results but it may take a while since I
> have
>  > to head to some meetings now. 
>  >  
>  > Thanks 
>  >  
>  >  
>  > 
>  >  Martha Yanez
>  >  (919) 224-1320 / 8-687-1320
>  >  New Notes id: Martha Yanez/Raleigh/IBM
>  >  my...@us...
>  >  
>  >  
>  >  
>  >  
>  >  
>  >  Grzegorz Lukasik <ha...@gm...> 
>  > 
>  > 04/02/2005 11:29 AM 
>  >  
>  > Please respond to
>  >  Grzegorz Lukasik 
>  >  
>  >  
>  > To Martha Yanez/Raleigh/IBM@IBMUS 
>  >  
>  > cc cob...@li... 
>  >  
>  > Subject Re: [Cobertura-devel] Having problems generating report, possible
>  > instrumentation problem as well 
>  >  
>  >  
>  >  
>  >  
>  >  
>  > ***********************
>  >  Warning: Your file, modified.jar, contains more than 32 files after
>  > decompression and cannot be scanned.
>  >  ***********************
>  > 
>  >  
>  >  
>  >  Hi
>  >  
>  >  I tried it the way you specified and it worked for me. Yours
>  >  cobertura.ser looks ok. It seems that there is something wrong with
>  >  reporting process - but i cannot reproduce behaviour you experienced.
>  >  I will try to help you - and us to find a bug.
>  >  
>  >  First
>  >  Could you create some empty directory and point cobertura to look for
>  >  sources there (using option -s) when using report generation?
>  >  
>  >  Second could you use attached jar (modified.jar) instead of
>  >  cobertura.jar? I modified two files (HTMLReport and Util) to show much
>  >  more information about things that happen. I also set there reporting
>  >  level to debug. Could you run reporting of your simple case and send
>  >  as what was logged? Modified files are attached.
>  >  
>  >  To increase the number of log messages in normal cobertura
>  >  distribution file you will have to edit cobertura.jar and in file
>  >  log4j.properties change debug level from WARN to DEBUG.
>  >  
>  >  Here is SourceForge archive for list cobertura-devel:
>  >
> https://sourceforge.net/mailarchive/forum.php?forum_id=44317
>  >  
>  >  Thanks for comprehensive description!
>  >  
>  >  Greetings
>  >  Grzegorz Lukasik 
>  >  
>  >  On Apr 2, 2005 1:17 AM, Martha Yanez <my...@us...> wrote:
>  >  >  
>  >  > 
>  >  >  Hi, 
>  >  > I'm trying to run cobertura with a tiny test program and having
> problem
>  >  > generating a report. 
>  >  > This is program, class files and ser output   . 
>  >  >  
>  >  > Cobertura.jar is in my classpath and I run following reporting command
>  > after
>  >  > executing DateUtil. 
>  >  >  
>  >  > C:\buildSLM>java
>  > net.sourceforge.cobertura.reporting.Main 
>  >  > -o c:\buildSLM\build-dir\r2 -i c:\buildSLM\cobertura.ser -s
> c:\buildSLM
>  > -f
>  >  > html 
>  >  >  
>  >  > The report command never terminates and my machine hits 100%
> processing
>  > when
>  >  > viewed under Task Manager 
>  >  > Some report files (index.html, frame-classes.html, frame-classes-.html
>  > (not
>  >  > a dup), frame-packages.html and frame-summary.html)  are generated
> very
>  >  > quickly at the start and then nothing.   
>  >  >  
>  >  >  
>  >  > I started this small test case because I suspect I may have an
>  >  > instrumentation problem. I tried instrumenting some of my product
> files
>  >  > (switching from the Jcoverage statements to the Cobertura ones
> Grzegorz
>  > was
>  >  > kind enough to send me this morning). It seems to go fine but when I
> ran
>  > the
>  >  > product I did not see the Cobertura.ser file being updated.  Since my
>  >  > product environment is a bit complex, I wanted to make sure I could
> get
>  > the
>  >  > simple test case working first and the little bit the report shows
> does
>  > seem
>  >  > like the test case ran (80%) but then the report problem comes in. If
> I
>  > try
>  >  > the ser file from my product instrumentation, the same thing happens
> (no
>  >  > termination - showing 0 coverage) 
>  >  >  
>  >  > Any help appreciated since I have limited time to get this working...
>  > also
>  >  > is there a debug or additional logging function I can turn on for more
>  > info
>  >  > on program execution?   
>  >  > One last thing... is there a way to see past mailing list entries? I'm
>  > now
>  >  > getting new updates but can't find past questions and hate to bother
> you
>  >  > asking something again that's been answered.   Thanks! 
>  >  > 
>  >  >  Martha Yanez
>  >  >  (919) 224-1320 / 8-687-1320
>  >  >  New Notes id: Martha Yanez/Raleigh/IBM
>  >  >  my...@us...
>  >  >  
>  >  >  
>  >  >
>  >  
>  >  [attachment "modified.jar" deleted by Martha Yanez/Raleigh/IBM]
> [attachment
>  > "log4j.properties" deleted by Martha Yanez/Raleigh/IBM] [attachment
>  > "Util.java" deleted by Martha Yanez/Raleigh/IBM] [attachment
>  > "HTMLReport.java" deleted by Martha Yanez/Raleigh/IBM] 
>  >  
>  >
>  
>  [attachment "modified.jar" deleted by Martha Yanez/Raleigh/IBM] 
>  
>

Re: [Cobertura-devel] Having problems generating report, possible instrumentation problem as well

[Grzegorz L. <ha...@gm...>]

Hi

Sory for bad file.
I have attached modified version of modified.jar.

Please send mi info if there are still some problems with it.

Grzegorz Lukasik 

On Apr 4, 2005 5:14 PM, Martha Yanez <my...@us...> wrote:
>  
> Hi Grzegorz 
> First of all... thanks for your speedy reply. I think I have an interesting
> clue to the problem - the size of the source directory is the key. My
> original product source directory is very big  (169 MB - 10, 172 files). 
> Even I was using the little test program (DateUtil) I had placed the source
> on my root build directory which is even bigger. When I place the source,
> and ser file in a unique directory, the report command works instantly.   
> I tried this after trying to point the source to an empty directory as you
> asked. The report command still hangs but I noticed that task's manager's
> performance was minimal ( not 100% as I observed earlier). That's what led
> me to suspect size of directory. 
> When I tried the modified jar, it hangs in all cases with an Exception in
> thread "main" java.lang.NoClassDefFoundError:
> net/sourceforge/cobertura/reporting/Util$1 but that is
> pointing to the following code: 
>  
>    private static Vector getListOfFiles(File file, boolean recursive) 
>         { 
>                 Vector ret = new Vector(); 
>                 logger.debug( "getListOfFiles file=" + file+ "
> recursive="+recursive); 
>  
>                 if (file.isFile()) 
>                 { 
>                         ret.add(file.getAbsolutePath()); 
>                 } 
>                 else if (file.isDirectory()) 
>                 { 
>                         File[] files = file.listFiles(new FileFilter() 
>                         { 
>                                 public boolean accept(File pathname) 
>                                 { 
>                                         return pathname.isDirectory() 
>                                                         ||
> pathname.getAbsolutePath().endsWith(".java"); 
>                                 } 
>                         }); 
>  
>                         for (int i = 0; i < files.length; i++) 
>                         { 
>                                 if (recursive) 
>                                 { 
>                                         ret.addAll(getListOfFiles(files[i],
> true)); 
>                                 } 
>                                 else 
>                                 { 
>                                         if (files[i].isFile()) 
>                                         { 
>                                                
> ret.add(files[i].getAbsolutePath()); 
>                                         } 
>                                 } 
>                         } 
>                 } 
>  
>  
> I can see how the size of the directory would overpower this loop. What is
> curious is that I used the same directory for my JCoverage reporting and had
> no problems in this area. Reporting would not be instant but would finished
> in a few minutes .  My problems with JCoverage were more in the area of
> random exceptions as I had my product running with major sections
> instrumented (about 900 classes). When I instrumented in smaller batches
> (200 classes or less), I could get viable ser files and generate reports. 
> Here is the output from the modified jar but again the exception terminated
> each before it could complete so I don't think this will be useful 
>  
>  
>  
> I just wanted to get this info to you quickly but I would like to run
> another test after pruning down my source directory to just the files I need
> to instrument. This may take a while and since the modified jar is having
> problems I was going to just run the original jar with the debug options you
> mentioned.  I'll let you know results but it may take a while since I have
> to head to some meetings now. 
>  
> Thanks 
>  
>  
> 
>  Martha Yanez
>  (919) 224-1320 / 8-687-1320
>  New Notes id: Martha Yanez/Raleigh/IBM
>  my...@us...
>  
>  
>  
>  
>  
>  Grzegorz Lukasik <ha...@gm...> 
> 
> 04/02/2005 11:29 AM 
>  
> Please respond to
>  Grzegorz Lukasik 
>  
>  
> To Martha Yanez/Raleigh/IBM@IBMUS 
>  
> cc cob...@li... 
>  
> Subject Re: [Cobertura-devel] Having problems generating report, possible
> instrumentation problem as well 
>  
>  
>  
>  
>  
> ***********************
>  Warning: Your file, modified.jar, contains more than 32 files after
> decompression and cannot be scanned.
>  ***********************
> 
>  
>  
>  Hi
>  
>  I tried it the way you specified and it worked for me. Yours
>  cobertura.ser looks ok. It seems that there is something wrong with
>  reporting process - but i cannot reproduce behaviour you experienced.
>  I will try to help you - and us to find a bug.
>  
>  First
>  Could you create some empty directory and point cobertura to look for
>  sources there (using option -s) when using report generation?
>  
>  Second could you use attached jar (modified.jar) instead of
>  cobertura.jar? I modified two files (HTMLReport and Util) to show much
>  more information about things that happen. I also set there reporting
>  level to debug. Could you run reporting of your simple case and send
>  as what was logged? Modified files are attached.
>  
>  To increase the number of log messages in normal cobertura
>  distribution file you will have to edit cobertura.jar and in file
>  log4j.properties change debug level from WARN to DEBUG.
>  
>  Here is SourceForge archive for list cobertura-devel:
> https://sourceforge.net/mailarchive/forum.php?forum_id=44317
>  
>  Thanks for comprehensive description!
>  
>  Greetings
>  Grzegorz Lukasik 
>  
>  On Apr 2, 2005 1:17 AM, Martha Yanez <my...@us...> wrote:
>  >  
>  > 
>  >  Hi, 
>  > I'm trying to run cobertura with a tiny test program and having problem
>  > generating a report. 
>  > This is program, class files and ser output   . 
>  >  
>  > Cobertura.jar is in my classpath and I run following reporting command
> after
>  > executing DateUtil. 
>  >  
>  > C:\buildSLM>java
> net.sourceforge.cobertura.reporting.Main 
>  > -o c:\buildSLM\build-dir\r2 -i c:\buildSLM\cobertura.ser -s c:\buildSLM
> -f
>  > html 
>  >  
>  > The report command never terminates and my machine hits 100% processing
> when
>  > viewed under Task Manager 
>  > Some report files (index.html, frame-classes.html, frame-classes-.html
> (not
>  > a dup), frame-packages.html and frame-summary.html)  are generated very
>  > quickly at the start and then nothing.   
>  >  
>  >  
>  > I started this small test case because I suspect I may have an
>  > instrumentation problem. I tried instrumenting some of my product files
>  > (switching from the Jcoverage statements to the Cobertura ones Grzegorz
> was
>  > kind enough to send me this morning). It seems to go fine but when I ran
> the
>  > product I did not see the Cobertura.ser file being updated.  Since my
>  > product environment is a bit complex, I wanted to make sure I could get
> the
>  > simple test case working first and the little bit the report shows does
> seem
>  > like the test case ran (80%) but then the report problem comes in. If I
> try
>  > the ser file from my product instrumentation, the same thing happens (no
>  > termination - showing 0 coverage) 
>  >  
>  > Any help appreciated since I have limited time to get this working...
> also
>  > is there a debug or additional logging function I can turn on for more
> info
>  > on program execution?   
>  > One last thing... is there a way to see past mailing list entries? I'm
> now
>  > getting new updates but can't find past questions and hate to bother you
>  > asking something again that's been answered.   Thanks! 
>  > 
>  >  Martha Yanez
>  >  (919) 224-1320 / 8-687-1320
>  >  New Notes id: Martha Yanez/Raleigh/IBM
>  >  my...@us...
>  >  
>  >  
>  >
>  
>  [attachment "modified.jar" deleted by Martha Yanez/Raleigh/IBM] [attachment
> "log4j.properties" deleted by Martha Yanez/Raleigh/IBM] [attachment
> "Util.java" deleted by Martha Yanez/Raleigh/IBM] [attachment
> "HTMLReport.java" deleted by Martha Yanez/Raleigh/IBM] 
>  
>

Re: [Cobertura-devel] Having problems generating report, possible instrumentation problem as well

[Grzegorz L. <ha...@gm...>]

Hi

I tried it the way you specified and it worked for me. Yours
cobertura.ser looks ok. It seems that there is something wrong with
reporting process - but i cannot reproduce behaviour you experienced.
I will try to help you - and us to find a bug.

First
Could you create some empty directory and point cobertura to look for
sources there (using option -s) when using report generation?

Second could you use attached jar (modified.jar) instead of
cobertura.jar? I modified two files (HTMLReport and Util) to show much
more information about things that happen. I also set there reporting
level to debug. Could you run reporting of your simple case and send
as what was logged? Modified files are attached.

To increase the number of log messages in normal cobertura
distribution file you will have to edit cobertura.jar and in file
log4j.properties change debug level from WARN to DEBUG.

Here is SourceForge archive for list cobertura-devel:
https://sourceforge.net/mailarchive/forum.php?forum_id=44317

Thanks for comprehensive description!

Greetings
Grzegorz Lukasik 

On Apr 2, 2005 1:17 AM, Martha Yanez <my...@us...> wrote:
>  
> 
>  Hi, 
> I'm trying to run cobertura with a tiny test program and having problem
> generating a report. 
> This is program, class files and ser output   . 
>  
> Cobertura.jar is in my classpath and I run following reporting command after
> executing DateUtil. 
>  
> C:\buildSLM>java net.sourceforge.cobertura.reporting.Main 
> -o c:\buildSLM\build-dir\r2 -i c:\buildSLM\cobertura.ser -s c:\buildSLM -f
> html 
>  
> The report command never terminates and my machine hits 100% processing when
> viewed under Task Manager 
> Some report files (index.html, frame-classes.html, frame-classes-.html (not
> a dup), frame-packages.html and frame-summary.html)  are generated very
> quickly at the start and then nothing.   
>  
>  
> I started this small test case because I suspect I may have an
> instrumentation problem. I tried instrumenting some of my product files
> (switching from the Jcoverage statements to the Cobertura ones Grzegorz was
> kind enough to send me this morning). It seems to go fine but when I ran the
> product I did not see the Cobertura.ser file being updated.  Since my
> product environment is a bit complex, I wanted to make sure I could get the
> simple test case working first and the little bit the report shows does seem
> like the test case ran (80%) but then the report problem comes in. If I try
> the ser file from my product instrumentation, the same thing happens (no
> termination - showing 0 coverage) 
>  
> Any help appreciated since I have limited time to get this working... also
> is there a debug or additional logging function I can turn on for more info
> on program execution?   
> One last thing... is there a way to see past mailing list entries? I'm now
> getting new updates but can't find past questions and hate to bother you
> asking something again that's been answered.   Thanks! 
> 
>  Martha Yanez
>  (919) 224-1320 / 8-687-1320
>  New Notes id: Martha Yanez/Raleigh/IBM
>  my...@us...
>  
>  
>

[Cobertura-devel] Having problems generating report, possible instrumentation problem as well

[Martha Y. <my...@us...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm=
l4/strict.dtd">=0A=0A<html>=0A<head>=0A<meta http-equiv=3D"Content-Type" co=
ntent=3D"text/html; charset=3DUTF-8" />=0A<title>Coverage Report</title>=0A=
</head>=0A=0A<frameset cols=3D"20%,80%">=0A	<frameset rows=3D"30%,70%">=0A	=
	<frame src=3D"frame-packages.html" name=3D"packageList" title=3D"All Packa=
ges"/>=0A		<frame src=3D"frame-classes.html" name=3D"classList" title=3D"Al=
l classes and interfaces (except non-static nested types)"/>=0A	</frameset>=
=0A	<frame src=3D"frame-summary.html" name=3D"summary" title=3D"Package, cl=
ass and interface descriptions" scrolling=3D"yes"/>=0A=0A	<noframes>=0A		<p=
>This document is designed to be viewed using the frames feature. If you se=
e this message, you are using a frame-incapable web client.</p>=0A		<p><a h=
ref=3D"frame-summary.html">Click here to view a non-frame version.</a></p>=
=0A	</noframes>=0A</frameset>=0A=0A</html>=0A=

RE: [Cobertura-devel] Maven plugin

[Jared R. <Jar...@sa...>]

Thanks Charles!=20
=20

> -----Original Message-----
> From: Charles Blaxland [mailto:Cha...@eb...]=20
> Sent: Thursday, March 31, 2005 9:05 PM
> To: Jared Richardson
> Cc: cob...@li...
> Subject: Re: [Cobertura-devel] Maven plugin
>=20
> Hi Jared,
>=20
> Here's a bit of a maven plugin primer for you.  In summary, until the=20
> cobertura plugin can be distributed as part of the maven project, I=20
> would add the source for the plugin into the cobertura CVS=20
> tree, build=20
> the plugin, and make it available for users to download from the=20
> cobertura website using "maven plugin:download".  You may=20
> also like to=20
> make the plugin's dependencies available somehow.  Details on=20
> how to do=20
> all this below...
>=20
>=20
> Building the Plugin
> -------------------
> The zip that I uploaded to JIRA is the source for the cobertura maven=20
> plugin.  To use it it needs to be packaged into a jar.  You=20
> can do this=20
> by running "maven plugin:install".  This will package it up in a jar=20
> (target/maven-cobertura-plugin-1.0.0.jar) and put it in your maven=20
> plugin dir ($MAVEN_HOME/plugins). Alternatively you could probably=20
> simply rename the zip I uploaded to a jar and manually copy it to the=20
> plugins dir.
>=20
>=20
> Distributing the plugin
> -----------------------
> Eventually you probably want to lobby the maven project to have the=20
> cobertura plugin distributed along with the maven releases,=20
> and have the=20
> source hosted and maintained as part of the maven project. =20
> Given that=20
> this process will take some time, and maven releases are pretty=20
> infrequent, you probably want to make it available from the cobertura=20
> website in the interim.  To do this:
> - Build the plugin
> - Put the build plugin in a directory=20
> "maven/cobertura/plugins" on the=20
> cobertura website.
> - Users should now be able to download the plugin with the following=20
> command:
> maven=20
> -Dmaven.repo.remote=3Dhttp://www.ibiblio.org/maven,http://cobert
> ura.sourceforge.net/maven=20
> -DgroupId=3Dcobertura -DartifactId=3Dmaven-cobertura-plugin=20
> -Dversion=3D1.0.0=20
> plugin:download
> - The plugin should then be available for use.
>=20
>=20
> Dependencies
> ------------
> Maven downloads all dependency jars from external repositories (eg:=20
> http://www.ibiblio.org/maven).  Each dependency is identified by a=20
> groupId, a name and a version.  So if maven needs a dependency with a=20
> groupId of "asm", a name of "asm" and a version "1.5.2" it=20
> will look in=20
> each external repository for a file "asm/jars/asm-1.5.2.jar".
>=20
> The cobertura plugin I wrote depends on the following=20
> (groupId/name/version):
> cobertura/cobertura/1.2
> asm/asm/2.0.RC1
> log4j/log4j/1.2.8
> urbanophile/java-getopt/1.0.9
> ncss/javancss/21.41
> ncss/ccl/21.41
>=20
> Of these, I couldn't find the cobertura, asm, and the ncss=20
> jars on the=20
> public maven repo (www.ibiblio.org/maven).  This will cause=20
> errors when=20
> users try to run the plugin, as not all deps will be found. =20
> There are a=20
> few options to fix this:
> - Tell users they need to install these dependencies into their local=20
> maven repo manually and give them instructions on how to do this.
> - Upload the missing dependencies to the public maven repo on=20
> ibiblio. =20
> Not sure what the process for this is. Its probably on the=20
> maven website.
> - Upload the missing dependencies to the maven repo on the cobertura=20
> website (ie: where you put the plugin).  Then users will have=20
> to run the=20
> cobertura plugin with the=20
> "-Dmaven.repo.remote=3Dhttp://www.ibiblio.org/maven,http://cober
> tura.sourceforge.net/maven"=20
> option at least the first time they run it so that maven can find the=20
> dependencies.
>=20
>=20
> Hope this helps.
>=20
> Cheers,
> Charles
>=20
>=20
>=20
>=20
> Jared Richardson wrote:
>=20
> >Hi Charles,
> >
> >I'm starting to play with Maven but am not an expert (or=20
> even a good user!) yet. Should any part of your note be added=20
> to the Cobertura docs so that people know how to use the=20
> plugin or does Maven present that information to the end users?
> >
> >Jared
> >=20
> >
> >
> >>-----Original Message-----
> >>From: cob...@li...=20
> >>[mailto:cob...@li...] On=20
> >>Behalf Of Charles Blaxland
> >>Sent: Tuesday, March 29, 2005 7:34 PM
> >>To: cob...@li...
> >>Subject: Re: [Cobertura-devel] Maven plugin
> >>
> >>Hi All,
> >>
> >>[I tried sending this mail previously with the plugin as an=20
> >>attachment, but it=20
> >>didn't seem to work - apologies if you get this twice. I've=20
> >>now attached the=20
> >>plugin to the maven JIRA issue at=20
> >>http://jira.codehaus.org/browse/MPJCOVERAGE-25]
> >>
> >>I have created a basic maven plugin for Cobertura. It is=20
> >>based on the existing=20
> >>jcoverage plugin, however it does NOT support generating its=20
> >>own HTML report=20
> >>based on the XML coverage output as the existing jcoverage=20
> >>plugin does - rather=20
> >>it simply delegates to the cobertura-report ant task to do=20
> >>this work.  The=20
> >>properties you can set are a subset of the jcoverage ones:
> >>
> >>maven.cobertura.dir=3D${maven.build.dir}/cobertura
> >>maven.cobertura.instrumentation=3D${maven.cobertura.dir}/classes
> >>maven.cobertura.junit.fork=3Dyes
> >>maven.cobertura.instrumentation.includes=3D**/*.class
> >>maven.cobertura.instrumentation.excludes=3DNOT_DEFINED
> >>
> >>The "cobertura" goal will instrument, run the tests and generate the
> >>report.  You can include the report in the site generation in=20
> >>the usual
> >>maven way.
> >>
> >>It depends on cobertura 1.2 at present. I couldn't find some of the
> >>dependencies on the maven repo on ibiblio, so there may be a few
> >>unsatisfied deps which require some manual installation when=20
> >>you run it
> >>(maybe these could be distributed with the plugin?).
> >>
> >>I've run it over a few of my projects (incl jdk1.5 ones) and=20
> >>it seems to
> >>work OK.
> >>
> >>Enjoy,
> >>Charles
> >>
> >>
> >>
>=20
>=20

Re: [Cobertura-devel] Congratulations on a great project... and some questions/suggestions.

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

On Fri, 1 Apr 2005 11:33:49 +1000, Nathan Johns wrote
> Would it be possible to change the class list in the bottom left 
> frame to be sorted by name rather than the whole classname & package 
> similar to javadoc.  It looks a little strange with the entire class 
> list being grouped and sorted by package but the package name not being
> displayed.

Yes, I didn't even realize it was like that.  I'll try to change that tonight.

> We were also keen to see some reporting on inner classes.  I have
> noted that a patch has been made to address this and I will try it 
> out shortly.  (Having spent most of this morning making our own 
> modifications to support inner classes in the html report, it will 
> be interesting to see this patch and how it is implemented.)

I haven't had a chance to look at the patch yet, but I'd like to release 1.3
soon after the inner class issue is resolved.

> Another thing that the my fellow developers were disappointed with 
> was the loss of line counts from the html report as compared to the 
> jcoverage report.  Were they removed for specific reasons and are 
> there any plans to put them back?  Given the wide variation of line 
> counts in our source and packages it give a better perspective of 
> coverage when shown a percent and what number of lines that 
> percentage is over.

Hmm, yeah.  I'll add that to the list of "things to add to the HTML reports if
you can find a goodp lace to put it."

> I also noted while looking at the code that method statistics are
> collected as well (hope I am correct in this).  Perhaps as an
> enhancment to the class overview pages which include the source, an
> additional section could be put at the top breaking the source file
> down by method.

That's a good idea--and very possible.

> I would also like to see the ant tasks improved to allow the location
> of the 'cobertura.ser' file to be specified.  Currently we have to
> move this file manually in our ant script between the instrument,
>  unit testing and reporting parts as they all look for the file in different
> locations. This is probably due to the complexity of our build not
> cobertura but having this flexibility would be good.

I agree completely.  I think I even filed a feature request for it so I
wouldn't forget.  (We also manually move the cobertura.ser file in our ant
scripts.)

> Can I also ask why cobertura ant tasks delegate to another JVM to run
> cobertura?  While this may be a hangover from jcoverage, to me it
> would make more sense to have the ant task just delegate to the
> cobertura classes directly.  The main methods on the cobertura entry
> points could be retained for those who wish to run it directly from
> the command line.

I came to the conclusion that it's a licensing issue.  Most of Cobertura is
GPL, but the ant tasks are Apache Source License, and the two licenses are
incompatable.  So for the ant tasks to call code from the rest of Cobertura
they must invoke a new JVM.  I belive that ant is also licensed under the
Apache Source License, so I do not think it is possible for an ant task to be
GPL.  Why the jcoverage people didn't choose a more appropriate license for
jcoverage (like ASL for everything)... your guess is as good as mine.

> Thanks for all the good work that is being put into cobertura.

No problem.  Thanks for the excellent feedback.  It's all very insightful and
polite.  I hope that a month or two from now you'll be able to step back and
take another look and let us know what still needs work.

-Mark

Re: [Cobertura-devel] Maven plugin

[Charles B. <Cha...@eb...>]

Hi Jared,

Here's a bit of a maven plugin primer for you.  In summary, until the 
cobertura plugin can be distributed as part of the maven project, I 
would add the source for the plugin into the cobertura CVS tree, build 
the plugin, and make it available for users to download from the 
cobertura website using "maven plugin:download".  You may also like to 
make the plugin's dependencies available somehow.  Details on how to do 
all this below...


Building the Plugin
-------------------
The zip that I uploaded to JIRA is the source for the cobertura maven 
plugin.  To use it it needs to be packaged into a jar.  You can do this 
by running "maven plugin:install".  This will package it up in a jar 
(target/maven-cobertura-plugin-1.0.0.jar) and put it in your maven 
plugin dir ($MAVEN_HOME/plugins). Alternatively you could probably 
simply rename the zip I uploaded to a jar and manually copy it to the 
plugins dir.


Distributing the plugin
-----------------------
Eventually you probably want to lobby the maven project to have the 
cobertura plugin distributed along with the maven releases, and have the 
source hosted and maintained as part of the maven project.  Given that 
this process will take some time, and maven releases are pretty 
infrequent, you probably want to make it available from the cobertura 
website in the interim.  To do this:
- Build the plugin
- Put the build plugin in a directory "maven/cobertura/plugins" on the 
cobertura website.
- Users should now be able to download the plugin with the following 
command:
maven 
-Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cobertura.sourceforge.net/maven 
-DgroupId=cobertura -DartifactId=maven-cobertura-plugin -Dversion=1.0.0 
plugin:download
- The plugin should then be available for use.


Dependencies
------------
Maven downloads all dependency jars from external repositories (eg: 
http://www.ibiblio.org/maven).  Each dependency is identified by a 
groupId, a name and a version.  So if maven needs a dependency with a 
groupId of "asm", a name of "asm" and a version "1.5.2" it will look in 
each external repository for a file "asm/jars/asm-1.5.2.jar".

The cobertura plugin I wrote depends on the following 
(groupId/name/version):
cobertura/cobertura/1.2
asm/asm/2.0.RC1
log4j/log4j/1.2.8
urbanophile/java-getopt/1.0.9
ncss/javancss/21.41
ncss/ccl/21.41

Of these, I couldn't find the cobertura, asm, and the ncss jars on the 
public maven repo (www.ibiblio.org/maven).  This will cause errors when 
users try to run the plugin, as not all deps will be found.  There are a 
few options to fix this:
- Tell users they need to install these dependencies into their local 
maven repo manually and give them instructions on how to do this.
- Upload the missing dependencies to the public maven repo on ibiblio.  
Not sure what the process for this is. Its probably on the maven website.
- Upload the missing dependencies to the maven repo on the cobertura 
website (ie: where you put the plugin).  Then users will have to run the 
cobertura plugin with the 
"-Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cobertura.sourceforge.net/maven" 
option at least the first time they run it so that maven can find the 
dependencies.


Hope this helps.

Cheers,
Charles




Jared Richardson wrote:

>Hi Charles,
>
>I'm starting to play with Maven but am not an expert (or even a good user!) yet. Should any part of your note be added to the Cobertura docs so that people know how to use the plugin or does Maven present that information to the end users?
>
>Jared
> 
>
>
>>-----Original Message-----
>>From: cob...@li... 
>>[mailto:cob...@li...] On 
>>Behalf Of Charles Blaxland
>>Sent: Tuesday, March 29, 2005 7:34 PM
>>To: cob...@li...
>>Subject: Re: [Cobertura-devel] Maven plugin
>>
>>Hi All,
>>
>>[I tried sending this mail previously with the plugin as an 
>>attachment, but it 
>>didn't seem to work - apologies if you get this twice. I've 
>>now attached the 
>>plugin to the maven JIRA issue at 
>>http://jira.codehaus.org/browse/MPJCOVERAGE-25]
>>
>>I have created a basic maven plugin for Cobertura. It is 
>>based on the existing 
>>jcoverage plugin, however it does NOT support generating its 
>>own HTML report 
>>based on the XML coverage output as the existing jcoverage 
>>plugin does - rather 
>>it simply delegates to the cobertura-report ant task to do 
>>this work.  The 
>>properties you can set are a subset of the jcoverage ones:
>>
>>maven.cobertura.dir=${maven.build.dir}/cobertura
>>maven.cobertura.instrumentation=${maven.cobertura.dir}/classes
>>maven.cobertura.junit.fork=yes
>>maven.cobertura.instrumentation.includes=**/*.class
>>maven.cobertura.instrumentation.excludes=NOT_DEFINED
>>
>>The "cobertura" goal will instrument, run the tests and generate the
>>report.  You can include the report in the site generation in 
>>the usual
>>maven way.
>>
>>It depends on cobertura 1.2 at present. I couldn't find some of the
>>dependencies on the maven repo on ibiblio, so there may be a few
>>unsatisfied deps which require some manual installation when 
>>you run it
>>(maybe these could be distributed with the plugin?).
>>
>>I've run it over a few of my projects (incl jdk1.5 ones) and 
>>it seems to
>>work OK.
>>
>>Enjoy,
>>Charles
>>
>>
>>

[Cobertura-devel] Congratulations on a great project... and some questions/suggestions.

[Nathan J. <nr...@gm...>]

Hi,

Previously we were using jcoverage but have just switched to cobertura
due to the ongoing development that is occurring.  Thanks to those
involved for making this fork of jcoverage.

Would it be possible to change the class list in the bottom left frame
to be sorted by name rather than the whole classname & package similar
to javadoc.  It looks a little strange with the entire class list
being grouped and sorted by package but the package name not being
displayed.

We were also keen to see some reporting on inner classes.  I have
noted that a patch has been made to address this and I will try it out
shortly.  (Having spent most of this morning making our own
modifications to support inner classes in the html report, it will be
interesting to see this patch and how it is implemented.)

Another thing that the my fellow developers were disappointed with was
the loss of line counts from the html report as compared to the
jcoverage report.  Were they removed for specific reasons and are
there any plans to put them back?  Given the wide variation of line
counts in our source and packages it give a better perspective of
coverage when shown a percent and what number of lines that percentage
is over.

I also noted while looking at the code that method statistics are
collected as well (hope I am correct in this).  Perhaps as an
enhancment to the class overview pages which include the source, an
additional section could be put at the top breaking the source file
down by method.

I would also like to see the ant tasks improved to allow the location
of the 'cobertura.ser' file to be specified.  Currently we have to
move this file manually in our ant script between the instrument, unit
testing and reporting parts as they all look for the file in different
locations. This is probably due to the complexity of our build not
cobertura but having this flexibility would be good.

Can I also ask why cobertura ant tasks delegate to another JVM to run
cobertura?  While this may be a hangover from jcoverage, to me it
would make more sense to have the ant task just delegate to the
cobertura classes directly.  The main methods on the cobertura entry
points could be retained for those who wish to run it directly from
the command line.

Thanks for all the good work that is being put into cobertura.  

Nathan Johns.

Re: [Cobertura-devel] newbie question

[Grzegorz L. <ha...@gm...>]

Hi

There is probably no documentation yet. But I can give you an example
how it can be done right now - if you are familliar with JCoverage it
can help.

NOTICE: I add cobertura.jar to the classpath. You have to either add
all libraries from cobertura lib/ directory to the classpath or pack
them to one jar (just as I did).

Greetings
Grzegorz Lukasik

------- Instrumentation ----------
java -cp lib\cobertura.jar
-Dnet.sourceforge.cobertura.rawcoverage.dir=d:\project\data
net.sourceforge.cobertura.coverage.Main -d
d:\project\build\instrumented\ d:\project\build\classes

------- Runing tests ----------
java -cp lib\cobertura.jar;d:\project\build\instrumented;d:\project\build\classes;d:\project\build\test-classes
-Dnet.sourceforge.cobertura.rawcoverage.dir=d:\project\data XSimpleTestCase

------- Generating report ----------
java -cp lib\cobertura.jar net.sourceforge.cobertura.reporting.Main -f
html -o d:\project\report -i d:\project\data\cobertura.ser -s
D:\project\src



On Thu, 31 Mar 2005 17:01:05 -0500, Martha Yanez <my...@us...> wrote:
>  
> I've been trying to get JCoverage working on my product and encountering
> problems. I just saw that your website and it seems to be actively
> supporting Coberture. I would like to try your code instead but only see ANT
> instructions. Do you have any doc on how to use your code outside of ANT
> (i.e like  an equivilent "java
> -Dcom.jcoverage.rawcoverage.dir=c:\buildSLM\build-dir\
> com.jcoverage.coverage.Instrument   -d
> c:\buildSLM\build-dir\jcoverTestInstrumented  TestUtil.class" command) 
>  
> thanks 
>  
> 
>  Martha Yanez
>  (919) 224-1320 / 8-687-1320
>  New Notes id: Martha Yanez/Raleigh/IBM
>  my...@us...
>  
>

[Cobertura-devel] newbie question

[Martha Y. <my...@us...>]

I've been trying to get JCoverage working on my product and encountering 
problems. I just saw that your website and it seems to be actively 
supporting Coberture. I would like to try your code instead but only see 
ANT instructions. Do you have any doc on how to use your code outside of 
ANT (i.e like  an equivilent "java 
-Dcom.jcoverage.rawcoverage.dir=c:\buildSLM\build-dir\ 
com.jcoverage.coverage.Instrument   -d 
c:\buildSLM\build-dir\jcoverTestInstrumented  TestUtil.class" command)

thanks


Martha Yanez
(919) 224-1320 / 8-687-1320
New Notes id: Martha Yanez/Raleigh/IBM
my...@us...

RE: [Cobertura-devel] Change type of .png files to binary in CVS.

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

There is a delay between the developer CVS (the "real" repository) and =
the anonymous CVS (used by viewcvs) on sourceforge.  The changes should =
show up within 10 hours, I think.

(Sourceforge continuously claims they're going to eliminate this delay, =
but it hasn't happened yet.)
-Mark

> -----Original Message-----
> From: Grzegorz Lukasik [mailto:ha...@gm...]=20
> Sent: Thursday, March 31, 2005 2:35 PM
> To: Mark Doliner
> Cc: cob...@li...
> Subject: Re: [Cobertura-devel] Change type of .png files to=20
> binary in CVS.
>=20
> Hi
>=20
> Yes, I mean these 3 files. But I do not see the new version of this
> file in CVS. Also here:
> http://cvs.sourceforge.net/viewcvs.py/cobertura/cobertura/src/
> net/sourceforge/cobertura/reporting/html/files/
> these files still have initial version (1.1.1.1).
>=20
> Grzegorz Lukasik
>=20
>=20
> On Thu, 31 Mar 2005 13:27:19 -0500, Mark Doliner=20
> <Mar...@sa...> wrote:
> > Thanks for pointing that out.  I just changed them to=20
> binary (at least, I think I did).  And I edited the=20
> cvswrappers file so that the default type for files like that=20
> should be binary.  Let me know if I missed anything (it's=20
> just the 3 files in the reporting/html/files directory, right?)
> > -Mark
> >=20
> > > -----Original Message-----
> > > From: cob...@li...
> > > [mailto:cob...@li...] On
> > > Behalf Of Grzegorz Lukasik
> > > Sent: Thursday, March 31, 2005 10:56 AM
> > > To: cob...@li...
> > > Subject: [Cobertura-devel] Change type of .png files to=20
> binary in CVS.
> > >
> > > Right now .png files are downloaded from CVS as text=20
> files but they
> > > should not - these images will not display on Windows=20
> becouse endlines
> > > are being changed.
> > >
> > > Grzegorz Lukasik
> >
>=20

Re: [Cobertura-devel] Change type of .png files to binary in CVS.

[Grzegorz L. <ha...@gm...>]

Hi

Yes, I mean these 3 files. But I do not see the new version of this
file in CVS. Also here:
http://cvs.sourceforge.net/viewcvs.py/cobertura/cobertura/src/net/sourceforge/cobertura/reporting/html/files/
these files still have initial version (1.1.1.1).

Grzegorz Lukasik


On Thu, 31 Mar 2005 13:27:19 -0500, Mark Doliner <Mar...@sa...> wrote:
> Thanks for pointing that out.  I just changed them to binary (at least, I think I did).  And I edited the cvswrappers file so that the default type for files like that should be binary.  Let me know if I missed anything (it's just the 3 files in the reporting/html/files directory, right?)
> -Mark
> 
> > -----Original Message-----
> > From: cob...@li...
> > [mailto:cob...@li...] On
> > Behalf Of Grzegorz Lukasik
> > Sent: Thursday, March 31, 2005 10:56 AM
> > To: cob...@li...
> > Subject: [Cobertura-devel] Change type of .png files to binary in CVS.
> >
> > Right now .png files are downloaded from CVS as text files but they
> > should not - these images will not display on Windows becouse endlines
> > are being changed.
> >
> > Grzegorz Lukasik
>

[Cobertura-devel] wish for a version 1.3 with multiple source directories support

[M C <mor...@ya...>]

Hi cobertura developers,

I just tried cobertura and it works well with simple
examples (I am using the ANT-task). Unfortunately I
can't use cobertura for real since the ANT task only
allows me to provide ONE single source directory
(srcdir) instead of multiple source directories as I
need! Any plans for a version 1.3 update with support
for multiple source directories (soon) :-)

BTW: Thanks for an otherwise great tool - Cool!

Sincerely,
Morten Christensen,
Århus, Denmark

 

RE: [Cobertura-devel] Maven plugin

[Jared R. <Jar...@sa...>]

Hi Charles,

I'm starting to play with Maven but am not an expert (or even a good =
user!) yet. Should any part of your note be added to the Cobertura docs =
so that people know how to use the plugin or does Maven present that =
information to the end users?

Jared
=20

> -----Original Message-----
> From: cob...@li...=20
> [mailto:cob...@li...] On=20
> Behalf Of Charles Blaxland
> Sent: Tuesday, March 29, 2005 7:34 PM
> To: cob...@li...
> Subject: Re: [Cobertura-devel] Maven plugin
>=20
> Hi All,
>=20
> [I tried sending this mail previously with the plugin as an=20
> attachment, but it=20
> didn't seem to work - apologies if you get this twice. I've=20
> now attached the=20
> plugin to the maven JIRA issue at=20
> http://jira.codehaus.org/browse/MPJCOVERAGE-25]
>=20
> I have created a basic maven plugin for Cobertura. It is=20
> based on the existing=20
> jcoverage plugin, however it does NOT support generating its=20
> own HTML report=20
> based on the XML coverage output as the existing jcoverage=20
> plugin does - rather=20
> it simply delegates to the cobertura-report ant task to do=20
> this work.  The=20
> properties you can set are a subset of the jcoverage ones:
>=20
> maven.cobertura.dir=3D${maven.build.dir}/cobertura
> maven.cobertura.instrumentation=3D${maven.cobertura.dir}/classes
> maven.cobertura.junit.fork=3Dyes
> maven.cobertura.instrumentation.includes=3D**/*.class
> maven.cobertura.instrumentation.excludes=3DNOT_DEFINED
>=20
> The "cobertura" goal will instrument, run the tests and generate the
> report.  You can include the report in the site generation in=20
> the usual
> maven way.
>=20
> It depends on cobertura 1.2 at present. I couldn't find some of the
> dependencies on the maven repo on ibiblio, so there may be a few
> unsatisfied deps which require some manual installation when=20
> you run it
> (maybe these could be distributed with the plugin?).
>=20
> I've run it over a few of my projects (incl jdk1.5 ones) and=20
> it seems to
> work OK.
>=20
> Enjoy,
> Charles
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>=20

RE: [Cobertura-devel] Change type of .png files to binary in CVS.

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

Thanks for pointing that out.  I just changed them to binary (at least, =
I think I did).  And I edited the cvswrappers file so that the default =
type for files like that should be binary.  Let me know if I missed =
anything (it's just the 3 files in the reporting/html/files directory, =
right?)
-Mark

> -----Original Message-----
> From: cob...@li...=20
> [mailto:cob...@li...] On=20
> Behalf Of Grzegorz Lukasik
> Sent: Thursday, March 31, 2005 10:56 AM
> To: cob...@li...
> Subject: [Cobertura-devel] Change type of .png files to binary in CVS.
>=20
> Right now .png files are downloaded from CVS as text files but they
> should not - these images will not display on Windows becouse endlines
> are being changed.
>=20
> Grzegorz Lukasik

[Cobertura-devel] Change type of .png files to binary in CVS.

[Grzegorz L. <ha...@gm...>]

Right now .png files are downloaded from CVS as text files but they
should not - these images will not display on Windows becouse endlines
are being changed.

Grzegorz Lukasik

Re: [Cobertura-devel] Coverage for inner classes.

[Grzegorz L. <ha...@gm...>]

I created a patch, so that Cobertura generates reports for inner and
anonymous classes - it is available on sourceforge site. There are
also coverage reports for simple project with and without the patch. 
I will describe here what have I done.

There is new class SourceFile. An instance of this class agregates
coverage data for all classes contained in one source file. This class
has now the methods to obtain coverage results - instead of Clazz as
was before.

In the class list (left bottom menu) you can see now inner classes -
If you click them you will see the source file that class is contained
in (TODO: maybe after the click the frame with source code should
point exactly to the place where the class is). Anonymous classes are
not visible in the class list - in fact they are treaten as part of
parent class.

Names of generated html pages changed slightly to reflect that they
are generated for source files, not for classes, for example:
was: simple.Simple.html 
is: simple.Simple.java.html 
If I look at this now, .java part should be removed ;)

Grzegorz Lukasik