From: Martha Y. <my...@us...> - 2005-04-01 23:17:57
|
<!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= |
From: Grzegorz L. <ha...@gm...> - 2005-04-02 16:29:13
|
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... > > > |
From: Grzegorz L. <ha...@gm...> - 2005-04-04 16:32:25
Attachments:
modified.jar
|
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] > > |
From: Grzegorz L. <ha...@gm...> - 2005-04-04 19:13:35
Attachments:
cobertura.jar
|
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] > > |
From: Grzegorz L. <ha...@gm...> - 2005-04-04 23:22:09
|
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] > > |
From: Grzegorz L. <ha...@gm...> - 2005-04-04 23:26:23
Attachments:
cobertura.jar
|
I attach Cobertura compiled from the newest sources from CVS - it should fix your problems. Thanks for your help! Greetings Grzegorz Lukasik |