Menu
▾
▴
cobertura-devel — General questions about using and developing Cobertura.
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(66) |
Apr
(29) |
May
(85) |
Jun
(66) |
Jul
(24) |
Aug
(139) |
Sep
(72) |
Oct
(26) |
Nov
(142) |
Dec
(34) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(55) |
Feb
(72) |
Mar
(43) |
Apr
(60) |
May
(95) |
Jun
(22) |
Jul
(48) |
Aug
(17) |
Sep
(54) |
Oct
(30) |
Nov
(82) |
Dec
(17) |
| 2007 |
Jan
(23) |
Feb
(38) |
Mar
(46) |
Apr
(12) |
May
(77) |
Jun
(77) |
Jul
(94) |
Aug
(51) |
Sep
(38) |
Oct
(57) |
Nov
(39) |
Dec
(67) |
| 2008 |
Jan
(38) |
Feb
(56) |
Mar
(42) |
Apr
(46) |
May
(37) |
Jun
(43) |
Jul
(52) |
Aug
(22) |
Sep
(22) |
Oct
(34) |
Nov
(37) |
Dec
(29) |
| 2009 |
Jan
(27) |
Feb
(35) |
Mar
(67) |
Apr
(37) |
May
(31) |
Jun
(79) |
Jul
(71) |
Aug
(59) |
Sep
(31) |
Oct
(47) |
Nov
(36) |
Dec
(7) |
| 2010 |
Jan
(15) |
Feb
(87) |
Mar
(38) |
Apr
(33) |
May
(24) |
Jun
(47) |
Jul
(26) |
Aug
(28) |
Sep
(33) |
Oct
(13) |
Nov
(8) |
Dec
(36) |
| 2011 |
Jan
(32) |
Feb
(10) |
Mar
(29) |
Apr
(29) |
May
(17) |
Jun
(14) |
Jul
(33) |
Aug
(11) |
Sep
(7) |
Oct
(7) |
Nov
(6) |
Dec
(10) |
| 2012 |
Jan
(19) |
Feb
(12) |
Mar
(16) |
Apr
(6) |
May
(18) |
Jun
(18) |
Jul
(31) |
Aug
(25) |
Sep
|
Oct
(31) |
Nov
(21) |
Dec
(9) |
| 2013 |
Jan
(8) |
Feb
(16) |
Mar
(8) |
Apr
(7) |
May
(3) |
Jun
(29) |
Jul
(29) |
Aug
|
Sep
(7) |
Oct
(9) |
Nov
(1) |
Dec
(1) |
| 2014 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
(13) |
May
(8) |
Jun
(5) |
Jul
(2) |
Aug
(4) |
Sep
(4) |
Oct
(2) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Declan B. <dec...@gm...> - 2005-09-08 04:39:21
|
Hi guys,
first a word of praise for your brilliant tool Cobertura which I have=20
started to use recently. I can really see the advantages of TFD coming into=
=20
play and cobertura will assist me in achieveing this.
I've setup my project instrumentation similar to the examples with=20
cobertura.1.6 but when I run the tests I get 0% coverage. However when I=20
changed the batchtest to use the .class files instead of the .java files it=
=20
seems to work ok.
i.e. I have in my build.xml file
=09<formatter type=3D"xml" />
=09<test name=3D"${testcase}" todir=3D"${reports.xml.dir}" if=3D"testcase" =
/>
=09<batchtest todir=3D"${reports.xml.dir}" unless=3D"testcase">
=09=09<fileset dir=3D"${project.classes.dir}">
=09=09=09<include name=3D"**/*Test.class/>
=09=09</fileset>
=09</batchtest>
instead of the recommended
=09<formatter type=3D"xml" />
=09<test name=3D"${testcase}" todir=3D"${reports.xml.dir}" if=3D"testcase" =
/>
=09<batchtest todir=3D"${reports.xml.dir}" unless=3D"testcase">
=09=09<fileset dir=3D"${test.src.dir}"> <!-- note this line is different -=
->
=09=09=09<include name=3D"**/*Test.java" /> <!-- as is this -->
=09=09</fileset>
=09</batchtest>
The first snippet works ok, but it should be the othe way around. What am I=
=20
doing wrong?
Cheers,
Dec.
|
|
From: Elliotte H. <el...@me...> - 2005-09-05 14:42:00
|
Carlos Sanchez wrote: > java.io.FileNotFoundException: Parent POM not found: > /Users/elharo/tmp/maven-plugins/plugin-project.xml > > You need to checkout the files in the root cvs dir > OK. I did that. There should be a way to check out just one plugin, but anyway it's building now. It ran and it generated coverage reports. However, the main frame page index.html seems to have a problem. It does not show any classes though the reports are there when I look at the framed pages individually. That is, frame-sourcefiles.html, frame-packages.html are empty like so: <html> <head> <title>Coverage Report Classes</title> <link title="Style" type="text/css" rel="stylesheet" href="css/main.css" /> </head> <body> <h5> All Packages </h5> <h5>Classes</h5> <table width="100%"> </td> </tr> </table> </body> </html> However, the individual package pages do list the classes in the package. Two build notes: 1. It would be helpful if a snapshot release were available somewhere other than CVS. 2. The version number should probably be 1.6 to match the Cobertura version rather than 1.1 -- Elliotte Rusty Harold el...@me... XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim |
|
From: Elliotte H. <el...@me...> - 2005-09-05 10:09:45
|
Cobertura is not the only coverage tool with this problem. It's one of the few places where untested code can't be tested but really shouldn't be deleted either. You could actually instantiate an object from within the class to force the test, or you could use setAccessible and reflection to instantiate an object from the test; but I'd recommend just living with this minor itch. You're likely to do more damage by scratching it. Really this is a case where Java's attempt to make the language easier causes some problems. If there were no automatically supplied public constructors, we wouldn't need to block them off with uncalled private ones. This is a case where making things easier for the novice really does make life harder for the expert. :-( -- Elliotte Rusty Harold el...@me... XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim |
|
From: Jeremy T. <jer...@gm...> - 2005-09-05 04:53:15
|
I feel the same way. I don't think anyone has looked into it much. But it=
=20
does open up some questions, as well. Like, how do you differentiate betwee=
n=20
a private constructor that should or should not be counted by default? My=
=20
suggestion would be to not count empty private constructors in an abstract=
=20
class so that you could combine abstract and an empty private constructor t=
o=20
signify that you should skip counting it. I wouldn't count it as covered,=
=20
but I'd leave it out of the line count. But no one has worked on anything=
=20
like this, and I'm not sure of its' feasibility at this point.
Jeremy Thomerson
On 9/3/05, David Kennedy <dav...@sw...> wrote:
>=20
> I've recently added Cobertura to our build and it's a *very* nice tool,
> and the reports are very polished. However, there's one bug that's
> annoying us, because it makes some simple classes look relatively=20
> untested.
>=20
> If we have a utility class Foo with mainly static methods and a private
> constructor (to stop instantiation), then we get private constructor
> lines containing only braces showing up as untested! Here's an ascii art=
=20
> report, where the RED lines are the problem:
>=20
> WHITE public class FooUtils
> WHITE {
> WHITE
> WHITE private FooUtils
> RED {
> WHITE // Deny instantiation
> RED }
> WHITE
> WHITE public boolean someTest(Object object)=20
> WHITE {
> GREEN return (object.someOperation() =3D=3D someResult);
> WHITE }
> WHITE }
>=20
> Any workaround? It upsets me not to have solid green results..
> --
> David Kennedy
> Software Engineer
> dav...@sw...
> http://www.swanlabs.com
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO=20
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...=20
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>=20
>=20
>
|
|
From: David K. <dav...@sw...> - 2005-09-03 22:45:18
|
I've recently added Cobertura to our build and it's a *very* nice tool,
and the reports are very polished. However, there's one bug that's
annoying us, because it makes some simple classes look relatively untested.
If we have a utility class Foo with mainly static methods and a private
constructor (to stop instantiation), then we get private constructor
lines containing only braces showing up as untested! Here's an ascii art
report, where the RED lines are the problem:
WHITE public class FooUtils
WHITE {
WHITE
WHITE private FooUtils
RED {
WHITE // Deny instantiation
RED }
WHITE
WHITE public boolean someTest(Object object)
WHITE {
GREEN return (object.someOperation() == someResult);
WHITE }
WHITE }
Any workaround? It upsets me not to have solid green results..
--
David Kennedy
Software Engineer
dav...@sw...
http://www.swanlabs.com
|
|
From: Grzegorz L. <ha...@gm...> - 2005-09-01 08:31:35
|
FYI ---------- Forwarded message ---------- From: hemalatha akondi <ako...@ya...> Date: Sep 1, 2005 10:05 AM Subject: Re: [Cobertura-devel] jdk1.3.1 support To: Grzegorz Lukasik <ha...@gm...> Thank you. It is working now.=20 =20 rgds,=20 Hema. Grzegorz Lukasik <ha...@gm...> wrote:=20 Hey, it seems that Cobertura 1.6 was compiled with JDK 1.4. Mark,=20 could you upload version compiled with 1.3? Grzegorz On 8/31/05, hemalatha akondi wrote: > Please see below stack trace.=20 >=20 > coverage-report: > [cobertura-report] Cobertura 1.6 - GNU GPL License (NO WARRANTY) - See > COPYRIGHT file > [cobertura-report] java.lang.NoSuchMethodError > [cobertura-report] at > net.sourceforge.cobertura.reporting.html.JavaToHtml.processLine(JavaToHtm= l.java:261) > [cobertura-report] at > net.sourceforge.cobertura.reporting.html.JavaToHtml.process(JavaToHtml.ja= va:136) > [cobertura-report] at > net.sourceforge.cobertura.reporting.html.HTMLReport.generateSourceFile(HT= MLReport.java:509) > [cobertura-report] at > net.sourceforge.cobertura.reporting.html.HTMLReport.generateSourceFiles(H= TMLReport.java:404) > [cobertura-report] at > net.sourceforge.cobertura.reporting.html.HTMLReport.(HTMLReport.java:81) > [cobertura-report] at > net.sourceforge.cobertura.reporting.Main.parseArguments(Main.java:100) > [cobertura-report] at > net.sourceforge.cobertura.reporting.Main.main(Main.java:161) > [cobertura-report] Exception in thread "main"=20 >=20 >=20 > -----------------------=20 > I did the following.=20 >=20 > 1. compiled the classes=20 > 2. instrumented the code=20 > 3. ran the test cases=20 > 4. ran the coverage report. >=20 >=20 > rgds,=20 > Hema.=20 >=20 >=20 >=20 >=20 > Grzegorz Lukasik wrote:=20 > Could you please include stack trace? It would be very helpful. >=20 > Grzegorz >=20 >=20 > On 8/30/05, hemalatha akondi wrote:=20 > >=20 > > It is not working with jdk 1.3.1. I am getting No such method > error(JavaToHtml class) while generating html report. The report just > contains the link for the test case but because of this error it is not > showing the code that has been covered and un covered. If i set to jdk1.4= , > it is showing the code.=20 > >=20 > > rgds,=20 > > Hema. > >=20 > > Grzegorz Lukasik wrote:=20 > > If I am right, Cobertura 1.6 (probably some previous versions also) > > should work with 1.3. Do you have any problems with it?=20 > >=20 > > Grzegorz > >=20 > > On 8/29/05, hemalatha akondi wrote: > > > I have started using Cobertura for my project. But we use jdk1.3.1. H= ow > do i > > > use cobertura for jdk1.3.1. Please let me know.=20 > > >=20 > > > rgds,=20 > > > Hema. > > >=20 > > > ________________________________ > > > Yahoo! Mail for Mobile > > > Take Yahoo! Mail with you! Check email on your mobile phone.=20 > > >=20 > > > > >=20 > >=20 > > ________________________________ > Start your day with Yahoo! - make it your home page=20 > >=20 > >=20 >=20 >=20 >=20 > ________________________________ > Yahoo! Mail > Stay connected, organized, and protected. Take the tour=20 >=20 > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Cobertura-devel mailing list Cob...@li... https://lists.sourceforge.net/lists/listinfo/cobertura-devel ________________________________ Start your day with Yahoo! - make it your home page |
|
From: Mark D. <Mar...@sa...> - 2005-08-31 14:45:11
|
Done. I'll try to be better about that in the future. http://cobertura.sourceforge.net/download.html -Mark=20 > -----Original Message----- > From: Grzegorz Lukasik [mailto:ha...@gm...]=20 > Sent: Wednesday, August 31, 2005 8:18 AM > To: hemalatha akondi; Mark Doliner > Cc: cobertura-devel > Subject: Re: [Cobertura-devel] jdk1.3.1 support >=20 > Hey, it seems that Cobertura 1.6 was compiled with JDK 1.4. >=20 > Mark,=20 > could you upload version compiled with 1.3? >=20 > Grzegorz >=20 > On 8/31/05, hemalatha akondi <ako...@ya...> wrote: > > Please see below stack trace.=20 > > =20 > > coverage-report: > > [cobertura-report] Cobertura 1.6 - GNU GPL License (NO=20 > WARRANTY) - See > > COPYRIGHT file > > [cobertura-report] java.lang.NoSuchMethodError > > [cobertura-report] at > >=20 > net.sourceforge.cobertura.reporting.html.JavaToHtml.processLin > e(JavaToHtml.java:261) > > [cobertura-report] at > >=20 > net.sourceforge.cobertura.reporting.html.JavaToHtml.process(Ja > vaToHtml.java:136) > > [cobertura-report] at > >=20 > net.sourceforge.cobertura.reporting.html.HTMLReport.generateSo > urceFile(HTMLReport.java:509) > > [cobertura-report] at > >=20 > net.sourceforge.cobertura.reporting.html.HTMLReport.generateSo > urceFiles(HTMLReport.java:404) > > [cobertura-report] at > >=20 > net.sourceforge.cobertura.reporting.html.HTMLReport.<init>(HTM > LReport.java:81) > > [cobertura-report] at > >=20 > net.sourceforge.cobertura.reporting.Main.parseArguments(Main.java:100) > > [cobertura-report] at > > net.sourceforge.cobertura.reporting.Main.main(Main.java:161) > > [cobertura-report] Exception in thread "main"=20 > > =20 > > =20 > > -----------------------=20 > > I did the following.=20 > > =20 > > 1. compiled the classes=20 > > 2. instrumented the code=20 > > 3. ran the test cases=20 > > 4. ran the coverage report. > > =20 > > =20 > > rgds,=20 > > Hema.=20 > > =20 > > =20 > >=20 > >=20 > > Grzegorz Lukasik <ha...@gm...> wrote:=20 > > Could you please include stack trace? It would be very helpful. > >=20 > > Grzegorz > >=20 > > =20 > > On 8/30/05, hemalatha akondi <ako...@ya...> wrote:=20 > > >=20 > > > It is not working with jdk 1.3.1. I am getting No such method > > error(JavaToHtml class) while generating html report. The=20 > report just > > contains the link for the test case but because of this=20 > error it is not > > showing the code that has been covered and un covered. If=20 > i set to jdk1.4, > > it is showing the code.=20 > > > =20 > > > rgds,=20 > > > Hema. > > >=20 > > > Grzegorz Lukasik <ha...@gm...> wrote:=20 > > > If I am right, Cobertura 1.6 (probably some previous=20 > versions also) > > > should work with 1.3. Do you have any problems with it?=20 > > >=20 > > > Grzegorz > > >=20 > > > On 8/29/05, hemalatha akondi wrote: > > > > I have started using Cobertura for my project. But we=20 > use jdk1.3.1. How > > do i > > > > use cobertura for jdk1.3.1. Please let me know.=20 > > > >=20 > > > > rgds,=20 > > > > Hema. > > > >=20 > > > > ________________________________ > > > > Yahoo! Mail for Mobile > > > > Take Yahoo! Mail with you! Check email on your mobile phone.=20 > > > >=20 > > > > > > >=20 > > >=20 > > > ________________________________ > > Start your day with Yahoo! - make it your home page=20 > > >=20 > > >=20 > >=20 > >=20 > >=20 > > ________________________________ > > Yahoo! Mail > > Stay connected, organized, and protected. Take the tour=20 > >=20 > > >=20 |
|
From: Grzegorz L. <ha...@gm...> - 2005-08-31 12:18:18
|
Hey, it seems that Cobertura 1.6 was compiled with JDK 1.4. Mark,=20 could you upload version compiled with 1.3? Grzegorz On 8/31/05, hemalatha akondi <ako...@ya...> wrote: > Please see below stack trace.=20 > =20 > coverage-report: > [cobertura-report] Cobertura 1.6 - GNU GPL License (NO WARRANTY) - See > COPYRIGHT file > [cobertura-report] java.lang.NoSuchMethodError > [cobertura-report] at > net.sourceforge.cobertura.reporting.html.JavaToHtml.processLine(JavaToHtm= l.java:261) > [cobertura-report] at > net.sourceforge.cobertura.reporting.html.JavaToHtml.process(JavaToHtml.ja= va:136) > [cobertura-report] at > net.sourceforge.cobertura.reporting.html.HTMLReport.generateSourceFile(HT= MLReport.java:509) > [cobertura-report] at > net.sourceforge.cobertura.reporting.html.HTMLReport.generateSourceFiles(H= TMLReport.java:404) > [cobertura-report] at > net.sourceforge.cobertura.reporting.html.HTMLReport.<init>(HTMLReport.jav= a:81) > [cobertura-report] at > net.sourceforge.cobertura.reporting.Main.parseArguments(Main.java:100) > [cobertura-report] at > net.sourceforge.cobertura.reporting.Main.main(Main.java:161) > [cobertura-report] Exception in thread "main"=20 > =20 > =20 > -----------------------=20 > I did the following.=20 > =20 > 1. compiled the classes=20 > 2. instrumented the code=20 > 3. ran the test cases=20 > 4. ran the coverage report. > =20 > =20 > rgds,=20 > Hema.=20 > =20 > =20 >=20 >=20 > Grzegorz Lukasik <ha...@gm...> wrote:=20 > Could you please include stack trace? It would be very helpful. >=20 > Grzegorz >=20 > =20 > On 8/30/05, hemalatha akondi <ako...@ya...> wrote:=20 > >=20 > > It is not working with jdk 1.3.1. I am getting No such method > error(JavaToHtml class) while generating html report. The report just > contains the link for the test case but because of this error it is not > showing the code that has been covered and un covered. If i set to jdk1.= 4, > it is showing the code.=20 > > =20 > > rgds,=20 > > Hema. > >=20 > > Grzegorz Lukasik <ha...@gm...> wrote:=20 > > If I am right, Cobertura 1.6 (probably some previous versions also) > > should work with 1.3. Do you have any problems with it?=20 > >=20 > > Grzegorz > >=20 > > On 8/29/05, hemalatha akondi wrote: > > > I have started using Cobertura for my project. But we use jdk1.3.1. H= ow > do i > > > use cobertura for jdk1.3.1. Please let me know.=20 > > >=20 > > > rgds,=20 > > > Hema. > > >=20 > > > ________________________________ > > > Yahoo! Mail for Mobile > > > Take Yahoo! Mail with you! Check email on your mobile phone.=20 > > >=20 > > > > >=20 > >=20 > > ________________________________ > Start your day with Yahoo! - make it your home page=20 > >=20 > >=20 >=20 >=20 >=20 > ________________________________ > Yahoo! Mail > Stay connected, organized, and protected. Take the tour=20 >=20 > |
|
From: Grzegorz L. <ha...@gm...> - 2005-08-29 07:55:28
|
If I am right, Cobertura 1.6 (probably some previous versions also) should work with 1.3. Do you have any problems with it? Grzegorz On 8/29/05, hemalatha akondi <ako...@ya...> wrote: > I have started using Cobertura for my project. But we use jdk1.3.1. How d= o i > use cobertura for jdk1.3.1. Please let me know.=20 > =20 > rgds,=20 > Hema. >=20 > ________________________________ > Yahoo! Mail for Mobile > Take Yahoo! Mail with you! Check email on your mobile phone.=20 >=20 > |
|
From: hemalatha a. <ako...@ya...> - 2005-08-29 07:51:51
|
I have started using Cobertura for my project. But we use jdk1.3.1. How do i use cobertura for jdk1.3.1. Please let me know. rgds, Hema. --------------------------------- Yahoo! Mail for Mobile Take Yahoo! Mail with you! Check email on your mobile phone. |
|
From: Grzegorz L. <ha...@gm...> - 2005-08-28 10:33:46
|
I think it is a good idea. I prefer solution with homegrown logging system, but I am probably in minority :) Your proposition is not so bad, so I think we should go this way. About removing classpath entry from jar vs. creating cobertura-runtime.jar, a drawback of first is that current users can depend on this entry (e.g. introduction section on Cobertura page). I like the idea of removing classpath if it will not hurt to much current users. Grzegorz On 8/26/05, Mark Doliner <Mar...@sa...> wrote: > How does everyone feel about the following changes? >=20 > Stop using logging in the "runtime" classes (all of our net.sourceforge.c= obertura.coveragedata classes). Instead, use System.out.println() to print= a message when saving and a message when loading the data file. And use S= ystem.err.println() in the event of an error. >=20 > Why is this good? It means people won't need to include our version of l= og4j in their project, potentially causing conflicts. All they'll need is = cobertura.jar (or cobertura-runtime.jar, if we decide to go that route). S= parse-and-useful output and error messages will always be printed to the co= nsole. This makes the information easy to find, and I do not believe users= will find it objectionable. >=20 > See the attached patch for my proposed changes. >=20 > If we do this, should we also stop including the "Class-path" in the cobe= rtura.jar manifest? It seems like having this class-path line here confuse= s people, and it's not THAT helpful. >=20 > -Mark >=20 >=20 > |
|
From: Mark D. <Mar...@sa...> - 2005-08-26 20:08:58
|
How does everyone feel about the following changes? Stop using logging in the "runtime" classes (all of our = net.sourceforge.cobertura.coveragedata classes). Instead, use = System.out.println() to print a message when saving and a message when = loading the data file. And use System.err.println() in the event of an = error. Why is this good? It means people won't need to include our version of = log4j in their project, potentially causing conflicts. All they'll need = is cobertura.jar (or cobertura-runtime.jar, if we decide to go that = route). Sparse-and-useful output and error messages will always be = printed to the console. This makes the information easy to find, and I = do not believe users will find it objectionable. See the attached patch for my proposed changes. If we do this, should we also stop including the "Class-path" in the = cobertura.jar manifest? It seems like having this class-path line here = confuses people, and it's not THAT helpful. -Mark |
|
From: Mark D. <Mar...@sa...> - 2005-08-26 19:37:47
|
It DOES sound like the maven plugin would benefit from putting =
cobertura.ser in some sort of "build" or "temp" directory. It sounds =
like the plugin needs to pass =
"-Dnet.sourceforge.cobertura.datafile=3D${build.dir}" to your JUnit =
tests to avoid having 2 copies of cobertura.ser
=20
-Mark
________________________________
From: cob...@li... =
[mailto:cob...@li...] On Behalf Of Chris =
DeJong
Sent: Friday, August 26, 2005 3:32 PM
To: cob...@li...
Subject: [Cobertura-devel] maven plugin and excludes
=09
=09
In case this is useful to other users of the maven plugin -=20
=20
I find that the cobertura.ser file needs to be deleted between runs in =
order to recognize a change to the =
maven.cobertura.instrumentation.excludes property. The default settings =
of the maven plugin put it in the project root directory, so running =
"maven clean" will not remove it. So I need to remove it manually.
=20
For example:
=20
1. I created a test app with=20
maven genapp
and modified AppTest to create an instance of App, and to call =
App.main(), for 100% coverage.
=20
2. ran=20
maven clean jar cobertura
and checked report in target/docs/cobertura/index.html. Saw App =
listed, with 100% coverage, as expected.
=20
3. ran=20
maven -Dmaven.cobertura.instrumentation.excludes=3D**/*.class clean jar =
cobertura
Expected this to exclude all class from instrumentation, but it didn't. =
Still got 100% coverage, because that .ser file was still there.
4. manually deleted the .ser file
5. ran that command from step 3 again, and then got an empty report per =
excludes, as expected=20
=20
This behaved the same way with the version of Cobertura that the maven =
plugin uses (1.4), or a plugin manually tweaked to use Cobertura 1.6.
=20
It seems that changing the location of the cobertura.ser file would =
help. However, if I modify the maven.cobertura.datafile property to =
${maven.build.dir}/cobertura.ser in order to put it in the target =
directory, where it will be deleted on a "maven clean", I end up with =
two cobertura.ser files, one in the project root and one in the target =
directory, and with report indicating 0% coverage.
=20
--Chris
=20
|
|
From: Chris D. <chr...@tv...> - 2005-08-26 19:32:11
|
In case this is useful to other users of the maven plugin -=20
=20
I find that the cobertura.ser file needs to be deleted between runs in
order to recognize a change to the
maven.cobertura.instrumentation.excludes property. The default settings
of the maven plugin put it in the project root directory, so running
"maven clean" will not remove it. So I need to remove it manually.
=20
For example:
=20
1. I created a test app with=20
maven genapp
and modified AppTest to create an instance of App, and to call
App.main(), for 100% coverage.
=20
2. ran=20
maven clean jar cobertura
and checked report in target/docs/cobertura/index.html. Saw App listed,
with 100% coverage, as expected.
=20
3. ran=20
maven -Dmaven.cobertura.instrumentation.excludes=3D**/*.class clean jar
cobertura
Expected this to exclude all class from instrumentation, but it didn't.
Still got 100% coverage, because that .ser file was still there.
4. manually deleted the .ser file
5. ran that command from step 3 again, and then got an empty report per
excludes, as expected=20
=20
This behaved the same way with the version of Cobertura that the maven
plugin uses (1.4), or a plugin manually tweaked to use Cobertura 1.6.
=20
It seems that changing the location of the cobertura.ser file would
help. However, if I modify the maven.cobertura.datafile property to
${maven.build.dir}/cobertura.ser in order to put it in the target
directory, where it will be deleted on a "maven clean", I end up with
two cobertura.ser files, one in the project root and one in the target
directory, and with report indicating 0% coverage.
=20
--Chris
=20
|
|
From: Carlos S. <ca...@ap...> - 2005-08-26 17:49:21
|
java.io.FileNotFoundException: Parent POM not found: /Users/elharo/tmp/maven-plugins/plugin-project.xml You need to checkout the files in the root cvs dir On 8/26/05, Elliotte Harold <el...@me...> wrote: > Carlos Sanchez wrote: > > Thanks for noticing the typo. I didn't use the plugin lately, so I > > wouldn't like to release it without testing, but if some users test > > latest cvs version and say it's ok I will cut a new release. >=20 >=20 > I checked it out of CVS but I get this error when trying to build: >=20 > ~/tmp/maven-plugins/cobertura$ maven -e > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 >=20 > org.apache.maven.MavenException: Error reading XML or initializing > at org.apache.maven.MavenUtils.getProject(MavenUtils.java:156) > at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) > at > org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232= ) > at org.apache.maven.MavenSession.initialize(MavenSession.java:17= 2) > at org.apache.maven.cli.App.doMain(App.java:475) > at org.apache.maven.cli.App.main(App.java:1239) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java= :39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI= mpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at com.werken.forehead.Forehead.run(Forehead.java:551) > at com.werken.forehead.Forehead.main(Forehead.java:581) > --- Nested Exception --- > java.io.FileNotFoundException: Parent POM not found: > /Users/elharo/tmp/maven-plugins/plugin-project.xml > at > org.apache.maven.MavenUtils.getNonJellyProject(MavenUtils.java:230) > at org.apache.maven.MavenUtils.getProject(MavenUtils.java:143) > at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) > at > org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232= ) > at org.apache.maven.MavenSession.initialize(MavenSession.java:17= 2) > at org.apache.maven.cli.App.doMain(App.java:475) > at org.apache.maven.cli.App.main(App.java:1239) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java= :39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI= mpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at com.werken.forehead.Forehead.run(Forehead.java:551) > at com.werken.forehead.Forehead.main(Forehead.java:581) >=20 > You have encountered an unknown error running Maven. Please help us to > correct > this problem by following these simple steps: > - read the Maven FAQ at http://maven.apache.org/faq.html > - run the same command again with the '-e' parameter, eg maven -e jar > - search the maven-user archives for the error at > http://nagoya.apache.org/eyebrowse/SummarizeList?listName=3Dusers@maven.a= pache.org > - post the output of maven -e to JIRA at > http://jira.codehaus.org/BrowseProject.jspa?id=3D10030 (you must sign up > first) > - run 'maven --info' and post the output as the environment to the bug ab= ove >=20 >=20 > Total time: 1 seconds > Finished at: Fri Aug 26 08:08:26 EDT 2005 >=20 > Any ideas? >=20 > -- > Elliotte Rusty Harold el...@me... > XML in a Nutshell 3rd Edition Just Published! > http://www.cafeconleche.org/books/xian3/ > http://www.amazon.com/exec/obidos/ISBN=3D0596007647/cafeaulaitA/ref=3Dnos= im > |
|
From: Elliotte H. <el...@me...> - 2005-08-26 12:10:09
|
Carlos Sanchez wrote:
> Thanks for noticing the typo. I didn't use the plugin lately, so I
> wouldn't like to release it without testing, but if some users test
> latest cvs version and say it's ok I will cut a new release.
I checked it out of CVS but I get this error when trying to build:
~/tmp/maven-plugins/cobertura$ maven -e
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
org.apache.maven.MavenException: Error reading XML or initializing
at org.apache.maven.MavenUtils.getProject(MavenUtils.java:156)
at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122)
at
org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232)
at org.apache.maven.MavenSession.initialize(MavenSession.java:172)
at org.apache.maven.cli.App.doMain(App.java:475)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
--- Nested Exception ---
java.io.FileNotFoundException: Parent POM not found:
/Users/elharo/tmp/maven-plugins/plugin-project.xml
at
org.apache.maven.MavenUtils.getNonJellyProject(MavenUtils.java:230)
at org.apache.maven.MavenUtils.getProject(MavenUtils.java:143)
at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122)
at
org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232)
at org.apache.maven.MavenSession.initialize(MavenSession.java:172)
at org.apache.maven.cli.App.doMain(App.java:475)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
You have encountered an unknown error running Maven. Please help us to
correct
this problem by following these simple steps:
- read the Maven FAQ at http://maven.apache.org/faq.html
- run the same command again with the '-e' parameter, eg maven -e jar
- search the maven-user archives for the error at
http://nagoya.apache.org/eyebrowse/SummarizeList?listName=us...@ma...
- post the output of maven -e to JIRA at
http://jira.codehaus.org/BrowseProject.jspa?id=10030 (you must sign up
first)
- run 'maven --info' and post the output as the environment to the bug above
Total time: 1 seconds
Finished at: Fri Aug 26 08:08:26 EDT 2005
Any ideas?
--
Elliotte Rusty Harold el...@me...
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
|
|
From: Chris D. <chr...@tv...> - 2005-08-26 00:46:56
|
Update: I manually upgraded the maven plugin to use Cobertura 1.6 and excludes started working. The version of the plugin I downloaded a few days ago uses Cobertura 1.4, and I couldn't get it to recognize excludes. =20 =20 ________________________________ From: cob...@li... [mailto:cob...@li...] On Behalf Of Chris DeJong Sent: Wednesday, August 24, 2005 6:55 PM To: cob...@li... Subject: [Cobertura-devel] excluding classes =20 Hi. I have a question about the maven plugin. =20 I'm trying to exclude a set of classes within a maven project, located in subdirectory target/jaxb, from inclusion in the coverage report. I've tried assigning different values to the "maven.cobertura.instrumentation.excludes" property in my maven build.properties file, such as "target/jaxb", with no luck. Even using "**/*.class" in there doesn't seem to affect the report. =20 Any suggestions? =20 Also, is there a key to the html report somewhere, or is it assumed to be self-explanatory? =20 =20 Thanks, Chris =20 |
|
From: Grzegorz L. <ha...@gm...> - 2005-08-25 19:59:52
|
Right now you can exclude classes from report during instrumentation. Simple examples: Excludes classes from package simple and all subpackages of simple: =09 <fileset dir=3D"build/classes"> =09=09<include name=3D"**/*.class"/> =09=09<exclude name=3D"simple/**/*.class"/> =09 </fileset> Excludes classes from package simple.second but not from subpackages (e.g. classes from package simple.second.hello will be visible in report). =09 <fileset dir=3D"build/classes"> =09=09<include name=3D"**/*.class"/> =09=09<exclude name=3D"simple/second/*.class"/> =09 </fileset> Grzegorz On 8/25/05, Chris DeJong <chr...@tv...> wrote: > =20 > =20 >=20 > Anyone have some sample ant or maven config settings for Cobertura that > excludes a directory of classes from the report?=20 >=20 > =20 >=20 > Thanks!=20 >=20 > =20 >=20 > --Chris |
|
From: Grzegorz L. <ha...@gm...> - 2005-08-25 19:54:50
|
Good. Thanks for patience! Grzegorz On 8/25/05, yamaduc <ya...@gm...> wrote: > yup, that worked. >=20 > On 8/25/05, yamaduc <ya...@gm...> wrote: > > Great! > > > > I'll try the hack for now. > > > > See if it works. > > > > thanks for all the help! > > > > On 8/25/05, Grzegorz Lukasik <ha...@gm...> wrote: > > > ---------- Forwarded message ---------- > > > From: Grzegorz Lukasik <ha...@gm...> > > > Date: Aug 25, 2005 9:12 PM > > > Subject: Re: [Cobertura-devel] reports not working properly > > > To: yamaduc <ya...@gm...> > > > > > > > > > It seems I have solution for the problem with Tomcat. When you shut > > > down Tomcat using CTRL+C under windows there are no problems with > > > Cobertura (then shutdown hooks - Tomcat's and Coberturas' - are > > > started together), but when you are using shutdown.bat the problem > > > with empty file appears becouse Cobertura shutdown hook is fired afte= r > > > Tomcat finishes all work. This log I found in catalina.out: > > > > > > > > > INFO: Stopping Coyote HTTP/1.1 on http-8081 > > > > > > INFO saveCoverageData, Saving coverage data to > > > D:\work\cactus-test\project\build\cobertura.ser > > > > > > Aug 25, 2005 8:57:00 PM org.apache.catalina.loader.WebappClassLoader = loadClass > > > > > > INFO: Illegal access: this web application instance has been stopped > > > already (the eventual following stack trace is caused by an error > > > thrown for debugging purposes as well as to attempt to terminate the > > > thread which caused the illegal access, and has no functional impact) > > > > > > > > > It seems that Cobertura tries to load some class for web application > > > and Tomcat does not allow for it after shutdown. > > > > > > Temporary solution is to _not_ include cobertura.jar (and others) > > > inside war, but put them inside common\lib Tomcat subdirectory. I wil= l > > > check if we can fix this problem so that no such hack will be needed. > > > > > > Grzegorz > > > > > > > > > On 8/25/05, yamaduc <ya...@gm...> wrote: > > > > I added <sleep seconds=3D"42"/> before the report call. > > > > > > > > It's still throwing the EOF Exception. > > > > > > > > I noticed David is having the same issue and he's correct, the > > > > cobertura.ser is empty before. > > > > > > > > On 8/25/05, Grzegorz Lukasik <ha...@gm...> wrote: > > > > > By default JBoss at the end of its shutdown uses > > > > > > > > > > Runtime.getRuntime().halt(0); > > > > > > > > > > so that JVM is forced to halt. If other shutdown hooks are workin= g > > > > > there are terminated - so Cobertura can be terminated in the midd= le of > > > > > serializing datafile (halt method documentation: > > > > > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html#ha= lt(int)) > > > > > > > > > > In case of Tomcat it seems that they do not use such brutal metho= ds, > > > > > and Cactus uses standard Tomcat shutdown. But Tomcat shutdown is = fired > > > > > from separate thread, maybe cobertura-report is run when Tomcat h= as > > > > > not finished its shutdown yet? Could you add sleep task before > > > > > launching cobertura-report? Maybe it will help. > > > > > > > > > > Below are presented some technical details and possible solution = for > > > > > JBoss users. > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > -----------------------------------------------------------------= --------------------------------------- > > > > > JBoss ServerImpl.java - source: > > > > > > > > > > http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-system/src/main= /org/jboss/system/server/ServerImpl.java?view=3Dmarkup > > > > > > > > > > Interesting sections: > > > > > > > > > > -------------- ServerImpl.java > > > > > public ShutdownHook(final ObjectName controller, final > > > > > ObjectName mainDeployer) > > > > > { > > > > > ... > > > > > > > > > > String value =3D System.getProperty("jboss.shutdown.forc= eHalt", null); > > > > > if (value !=3D null) { > > > > > forceHalt =3D new Boolean(value).booleanValue(); > > > > > } > > > > > -------------- > > > > > public void run() > > > > > { > > > > > shutdown(); > > > > > > > > > > // later bitch > > > > > if (forceHalt) { > > > > > System.out.println("Halting VM"); > > > > > Runtime.getRuntime().halt(0); > > > > > } > > > > > } > > > > > -------------- > > > > > BTW. Nice comment ;) > > > > > > > > > > -----------------------------------------------------------------= --------------------------------------- > > > > > JBoss changelog: > > > > > > > > > > http://sourceforge.net/project/shownotes.php?release_id=3D97289 > > > > > > > > > > Section: Changes between JBoss_3_0_1RC1 and JBoss_3_0_0 > > > > > > > > > > Added jboss.shutdown.forceHalt system property, which defaults to= true. > > > > > This value controls whether or not the shutdown hook will fo= rce the vm > > > > > to exit after shutdown has been completed. This might help = for situations > > > > > where the vm is crazy, locked up in socket io or something..= . or not. > > > > > > > > > > ------------ > > > > > You can use this option to prevent Runtime.halt use: > > > > > > > > > > run -Djboss.shutdown.forceHalt=3Dfalse > > > > > > > > > > You should see these lines at JBoss shutdown (this lines are writ= ten > > > > > on standard output, so won't see them in logs): > > > > > Shutdown complete > > > > > > > > > > When this option is not used additionaly this line is presented: > > > > > Shutdown complete > > > > > Halting VM > > > > > > > > > > NOTICE: I will be able to test it with Cobertura installation on = Linux tomorrow. > > > > > > > > > > > > > > > On 8/24/05, yamaduc <ya...@gm...> wrote: > > > > > > Here's the stack, see below. > > > > > > > > > > > > Thanks for your help. > > > > > > > > > > > > Maybe I can get a thread dump, if that'll help. > > > > > > > > > > > > > > > > > > [cobertura-report] java.io.EOFException > > > > > > [cobertura-report] at > > > > > > java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInput= Stream.java:2165) > > > > > > [cobertura-report] at > > > > > > java.io.ObjectInputStream$BlockDataInputStream.readShort(Object= InputStream.java:2631) > > > > > > [cobertura-report] at > > > > > > java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.ja= va:734) > > > > > > [cobertura-report] at > > > > > > java.io.ObjectInputStream.<init>(ObjectInputStream.java:253) > > > > > > [cobertura-report] at > > > > > > net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler.= loadCoverageData(CoverageDataFileHandler.java:97) > > > > > > [cobertura-report] at > > > > > > net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler.= loadCoverageData(CoverageDataFileHandler.java:68) > > > > > > [cobertura-report] at > > > > > > net.sourceforge.cobertura.reporting.Main.parseArguments(Main.ja= va:91) > > > > > > [cobertura-report] at > > > > > > net.sourceforge.cobertura.reporting.Main.main(Main.java:161) > > > > > > > > > > > > > > > > > > > > > > > > On 8/24/05, Grzegorz Lukasik <ha...@gm...> wrote: > > > > > > > Yeah, it looks pretty strange. I have noticed it recently whe= n running > > > > > > > instrumented application in JBoss. On Windows it worked ok, b= ut under > > > > > > > Linux I got EOFException when reporting task was reading cobe= rtura.ser > > > > > > > - it seems that cobertura.ser was truncated (or maybe not ful= ly > > > > > > > written) during instrumentation. I have no time to investigat= e it yet, > > > > > > > but now I see it was no accident, and I will look at it. > > > > > > > > > > > > > > cobertura.ser is written during virtual machine shutdown, may= be some > > > > > > > applications that also perfom some actions on VM shutdown use > > > > > > > java.lang.Runtime.halt method at the end? I am not sure. > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > PS. Eh, I won't be able to do anything today. > > > > > > > > > > > > > > On 8/24/05, yamaduc <ya...@gm...> wrote: > > > > > > > > well, this is strange. > > > > > > > > > > > > > > > > I put all the cobertura jar in the war file. > > > > > > > > > > > > > > > > The classes get instrumented, but during the report, it del= etes > > > > > > > > everything in the cobertura.ser > > > > > > > > > > > > > > > > Then an EOF exception is thrown. > > > > > > > > > > > > > > > > On 8/24/05, Grzegorz Lukasik <ha...@gm...> wrote: > > > > > > > > > Hmmmm... I am not sure what is the cause. Have you add co= bertura.jar > > > > > > > > > and all depended libraries to the war (or to Tomcat's lib= directory)? > > > > > > > > > And have you put all classes and other resources that wer= e not > > > > > > > > > instrumented (e.g. interfaces, files with properties) to = these > > > > > > > > > instrumented? > > > > > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > > > > On 8/24/05, yamaduc <ya...@gm...> wrote: > > > > > > > > > > Cobertura isn't throwing any exception. > > > > > > > > > > If I put the instrumented classes in the war file I get= the following error. > > > > > > > > > > > > > > > > > > > > [cactus] ----------------------------------------------= ------------------- > > > > > > > > > > [cactus] Running tests against Tomcat 4.1.27 @ http://l= ocalhost:8810 > > > > > > > > > > [cactus] ----------------------------------------------= ------------------- > > > > > > > > > > [cactus] Testsuite: com.goldengate.veridata.struts.acti= ons.TestCreateGroupAction > > > > > > > > > > [cactus] Tests run: 1, Failures: 0, Errors: 1, Time ela= psed: 0.63 sec > > > > > > > > > > > > > > > > > > > > [cactus] ------------- Standard Error ----------------- > > > > > > > > > > [cactus] log4j:WARN No appenders could be found for log= ger > > > > > > > > > > (org.apache.cactus.internal.configuration.Configuration= Initializer). > > > > > > > > > > [cactus] log4j:WARN Please initialize the log4j system = properly. > > > > > > > > > > [cactus] ------------- ---------------- --------------- > > > > > > > > > > [cactus] Testcase: > > > > > > > > > > testExceptionBean(org.apache.cactus.ServletTestCase): = Caused an > > > > > > > > > > ERROR > > > > > > > > > > [cactus] Error while initializing ActionServlet: Parsin= g error > > > > > > > > > > processing resource path /WEB-INF/struts-config.xml > > > > > > > > > > [cactus] junit.framework.AssertionFailedError: Error wh= ile > > > > > > > > > > initializing ActionServlet: Parsing error processing re= source path > > > > > > > > > > /WEB-INF/struts-config. > > > > > > > > > > [cactus] at > > > > > > > > > > servletunit.struts.CactusStrutsTestCase.getActionServle= t(CactusStrutsTestCase.java:486) > > > > > > > > > > [cactus] at > > > > > > > > > > servletunit.struts.CactusStrutsTestCase.actionPerform(C= actusStrutsTestCase.java:536) > > > > > > > > > > [cactus] at > > > > > > > > > > com.goldengate.veridata.struts.actions.TestCreateGroupA= ction.testExceptionBean(TestCreateGroupAction.java:63) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.cactus.internal.AbstractCactusTestCase.runBa= reServer(AbstractCactusTestCase.java:153) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.cactus.internal.server.AbstractWebTestCaller= .doTest(AbstractWebTestCaller.java:119) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.cactus.internal.server.AbstractWebTestContro= ller.handleRequest_aroundBody0(AbstractWebTestController.java:93) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.cactus.internal.server.AbstractWebTestContro= ller.handleRequest_aroundBody1$advice(AbstractWebTestController.java:217) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.cactus.internal.server.AbstractWebTestContro= ller.handleRequest(AbstractWebTestController.java) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.cactus.server.ServletTestRedirector.doPost_a= roundBody2(ServletTestRedirector.java:101) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.cactus.server.ServletTestRedirector.doPost_a= roundBody3$advice(ServletTestRedirector.java:217) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.cactus.server.ServletTestRedirector.doPost(S= ervletTestRedirector.java) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.cactus.server.ServletTestRedirector.doGet_ar= oundBody0(ServletTestRedirector.java:72) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.cactus.server.ServletTestRedirector.doGet_ar= oundBody1$advice(ServletTestRedirector.java:217) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.cactus.server.ServletTestRedirector.doGet(Se= rvletTestRedirector.java) > > > > > > > > > > [cactus] at javax.servlet.http.HttpServlet.service(= HttpServlet.java:740) > > > > > > > > > > [cactus] at javax.servlet.http.HttpServlet.service(= HttpServlet.java:853) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.interna= lDoFilter(ApplicationFilterChain.java:247) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilte= r(ApplicationFilterChain.java:193) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardWrapperValve.invoke(St= andardWrapperValve.java:256) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardPipeline$StandardPipel= ineValveContext.invokeNext(StandardPipeline.java:643) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardPipeline.invoke(Standa= rdPipeline.java:480) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.ContainerBase.invoke(Container= Base.java:995) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardContextValve.invoke(St= andardContextValve.java:191) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardPipeline$StandardPipel= ineValveContext.invokeNext(StandardPipeline.java:643) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardPipeline.invoke(Standa= rdPipeline.java:480) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.ContainerBase.invoke(Container= Base.java:995) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardContext.invoke(Standar= dContext.java:2416) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardHostValve.invoke(Stand= ardHostValve.java:180) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardPipeline$StandardPipel= ineValveContext.invokeNext(StandardPipeline.java:643) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.valves.ErrorDispatcherValve.invoke(= ErrorDispatcherValve.java:171) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardPipeline$StandardPipel= ineValveContext.invokeNext(StandardPipeline.java:641) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.valves.ErrorReportValve.invoke(Erro= rReportValve.java:172) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardPipeline$StandardPipel= ineValveContext.invokeNext(StandardPipeline.java:641) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardPipeline.invoke(Standa= rdPipeline.java:480) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.ContainerBase.invoke(Container= Base.java:995) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardEngineValve.invoke(Sta= ndardEngineValve.java:174) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardPipeline$StandardPipel= ineValveContext.invokeNext(StandardPipeline.java:643) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.StandardPipeline.invoke(Standa= rdPipeline.java:480) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.core.ContainerBase.invoke(Container= Base.java:995) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.connector.http.HttpProcessor.proces= s(HttpProcessor.java:1040) > > > > > > > > > > [cactus] at > > > > > > > > > > org.apache.catalina.connector.http.HttpProcessor.run(Ht= tpProcessor.java:1151) > > > > > > > > > > [cactus] at java.lang.Thread.run(Thread.java:534) > > > > > > > > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote: > > > > > > > > > > > Try to run ant with -v option, there should be stack = trace with more detail. > > > > > > > > > > > Did you put only instrumented classes into war? If Co= bertura does not > > > > > > > > > > > instrument class for some reason (e.g. for interface)= it does not put > > > > > > > > > > > uninstrumented file among instrumented. Maybe some in= terface is > > > > > > > > > > > missing? (You should copy all remaining files to the = war). > > > > > > > > > > > > > > > > > > > > > > Or maybe Cobertura library is not in Tomcat libs? > > > > > > > > > > > > > > > > > > > > > > I am just guessing. > > > > > > > > > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > > > > > > > > PS. I am going sleep, so I won't be able to answer to= day. > > > > > > > > > > > > > > > > > > > > > > On 8/24/05, yamaduc <ya...@gm...> wrote: > > > > > > > > > > > > Here's what happens when i put the instrumented cla= sses in the war file. > > > > > > > > > > > > > > > > > > > > > > > > [cactus] Testcase: > > > > > > > > > > > > testExceptionBean(org.apache.cactus.ServletTestCase= ): Caused an > > > > > > > > > > > > ERROR > > > > > > > > > > > > [cactus] Error while initializing ActionServlet: Pa= rsing error > > > > > > > > > > > > processing resource path /WEB-INF/struts-config.xml > > > > > > > > > > > > [cactus] junit.framework.AssertionFailedError: Erro= r while > > > > > > > > > > > > initializing ActionServlet: Parsing error processin= g resource path > > > > > > > > > > > > /WEB-INF/struts-config.xml > > > > > > > > > > > > > > > > > > > > > > > > I tried it without the instrumented classes in the = war file and this > > > > > > > > > > > > message does not appear. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wr= ote: > > > > > > > > > > > > > If you put insturmented classes in serverclasses = dir for Weblogic, > > > > > > > > > > > > > then they were treaten as part of web application= . > > > > > > > > > > > > > > > > > > > > > > > > > > You can try (at least for test) to instrument war= - it should be > > > > > > > > > > > > > possible from Cobertura 1.5. Be aware that you wi= ll need cobertura.jar > > > > > > > > > > > > > (and dependend) in some tomcat lib subdirectory (= or you can pack it > > > > > > > > > > > > > into war). > > > > > > > > > > > > > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote: > > > > > > > > > > > > > > I had this working before with weblogic just fi= ne. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm using tomcat now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > With weblogic, i didn't need to put the instrum= ented classes in the > > > > > > > > > > > > > > war/ear file. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I put the instrumented classes in the server's = classpath and it worked fine. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'll try to put them in the war and see what ha= ppens. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...= > wrote: > > > > > > > > > > > > > > > Correct me if I'm wrong, cactus task work thi= s way: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - deploy war inside application container > > > > > > > > > > > > > > > - run tests on deployed application by cac= tus > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So if I get it right, classes packed into war= are used when performing > > > > > > > > > > > > > > > tests. When you specifiy classpath inside cac= tus task, it specifies > > > > > > > > > > > > > > > classpath for test classes. So you need instu= rmented classes packed > > > > > > > > > > > > > > > into war, so that they are run during tests. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote= : > > > > > > > > > > > > > > > > so i should have the instrumented classes i= nstead of the standard classes? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <hauserx@gmail= .com> wrote: > > > > > > > > > > > > > > > > > One more hit, maybe in created war you do= not have instrumented classes? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> w= rote: > > > > > > > > > > > > > > > > > > The date never changes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <hauserx@g= mail.com> wrote: > > > > > > > > > > > > > > > > > > > Yes, it should be updated when tests = are run but size will be the > > > > > > > > > > > > > > > > > > > same. Check file change date. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reports does not update cobertura.ser= . > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...= m> wrote: > > > > > > > > > > > > > > > > > > > > Is the cobertura.ser supposed to up= date during the report process? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I watched it after instrumentation,= its 691k. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > After my tests run and the reports = are executed, it's still the same 691k. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, yamaduc <yamaduc@gmail.= com> wrote: > > > > > > > > > > > > > > > > > > > > > Well, I tried passing it in as a = runtime paramter to the jvm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then the report task complained, = couldn't find cobertura.ser. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, I added datafile to the ant t= ask and the error message went away, > > > > > > > > > > > > > > > > > > > > > see ant target below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I only have one .ser file. > > > > > > > > > > > > > > > > > > > > > <cobertura-instrument datafile=3D= "${test.dir}/cobertura.ser" > > > > > > > > > > > > > > > > > > > > > todir=3D"${instrumented.classes}"= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <target name=3D"coverage"= description=3D"HTML coverage reports can be > > > > > > > > > > > > > > > > > > > > > found in build/coverage"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <mkdir dir=3D"${t= est.results}/coverage"/> > > > > > > > > > > > > > > > > > > > > > <cobertura-report= srcdir=3D"${src.dir}" > > > > > > > > > > > > > > > > > > > > > destdir=3D"${test.results}/covera= ge" > > > > > > > > > > > > > > > > > > > > > datafile=3D"${test.dir}/cobertura= .ser"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <echo> > > > > > > > > > > > > > > > > > > > > > Cobertura= reports have been generated. > > > > > > > > > > > > > > > > > > > > > The HTML = report is ${test.results}/coverage/index.html > > > > > > > > > > > > > > > > > > > > > </echo> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > </target> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <hau= se...@gm...> wrote: > > > > > > > > > > > > > > > > > > > > > > Hey, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You probably do not set propert= y net.sourceforge.cobertura.datafile > > > > > > > > > > > > > > > > > > > > > > when running tests (I do not kn= ow how to do it inside cactus task). Do > > > > > > > > > > > > > > > > > > > > > > you get additional cobertura.se= r in directory where tests are run? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, yamaduc <yamaduc@gm= ail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have the following build sc= ript. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <target name=3D"instrument" d= epends=3D"compile" description=3D"Add Cobertura > > > > > > > > > > > > > > > > > > > > > > > instrumentation"> > > > > > > > > > > > > > > > > > > > > > > > <!-- instrume= nt the application classes, writing the instrumented > > > > > > > > > > > > > > > > > > > > > > > classes into ${instrumented.c= lasses}. --> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <cobertura-in= strument datafile=3D"${test.dir}/cobertura.ser" > > > > > > > > > > > > > > > > > > > > > > > todir=3D"${instrumented.class= es}"> > > > > > > > > > > > > > > > > > > > > > > > <!-- = Note that the following line causes instrument to ignore any > > > > > > > > > > > > > > > > > > > > > > > = source line containing a reference to log4j, for the purposes > > > > > > > > > > > > > > > > > > > > > > > = of coverage reporting. --> > > > > > > > > > > > > > > > > > > > > > > > <igno= re regex=3D"org.apache.log4j.*"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <file= set dir=3D"${classes.dir}"> > > > > > > > > > > > > > > > > > > > > > > > = <!-- instrument all the application classes, but don't instrument > > > > > > > > > > > > > > > > > > > > > > > the test classes. --> > > > > > > > > > > > > > > > > > > > > > > > = <include name=3D"**/*.class"/> > > > > > > > > > > > > > > > > > > > > > > > = <exclude name=3D"**/*Test.class"/> > > > > > > > > > > > > > > > > > > > > > > > </fil= eset> > > > > > > > > > > > > > > > > > > > > > > > </cobertura-i= nstrument> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > </target> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <target name=3D"test" depends= =3D"prepare.test.package" description=3D"Run > > > > > > > > > > > > > > > > > > > > > > > the tests on the defined cont= ainer"> > > > > > > > > > > > > > > > > > > > > > > > <!-- Run the = tests --> > > > > > > > > > > > > > > > > > > > > > > > <mkdir dir=3D= "${test.results}/tomcat4x"/> > > > > > > > > > > > > > > > > > > > > > > > <cactus warfi= le=3D"${test-war.dir}/${app.name}-${app.version}.war" > > > > > > > > > > > > > > > > > > > > > > > fork=3D"yes" failureproperty= =3D"tests.failed" haltonerror=3D"true"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <!-- = Configure the cactus task for logging --> > > > > > > > > > > > > > > > > > > > > > > > <cact= usproperty server=3D"false" > > > > > > > > > > > > > > > > > > > > > > > = propertiesFile=3D"${meta.dir}/${configtype}/test/logging_client.properti= es"/> > > > > > > > > > > > > > > > > > > > > > > > <cact= usproperty server=3D"true" > > > > > > > > > > > > > > > > > > > > > > > = propertiesFile=3D"${meta.dir}/${configtype}/test/logging_server.properti= es"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <!-- = Additional jars that will be added to the classpath used to start the > > > > > > > > > > > > > > > > > > > > > > > = container (in addition to the container jars themseleves which are > > > > > > > > > > > > > > > > > > > > > > > = automatically added by the <cactus> task --> > > > > > > > > > > > > > > > > > > > > > > > <cont= ainerclasspath> > > > > > > > > > > > > > > > > > > > > > > > = <pathelement path=3D"${test-props.dir}"/> > > > > > > > > > > > > > > > > > > > > > > > </con= tainerclasspath> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <clas= spath> > > > > > > > > > > > > > > > > > > > > > > > = <pathelement path=3D"${instrumented.classes}"/> > > > > > > > > > > > > > > > > > > > > > > > = <pathelement path=3D"${classes.dir}"/> > > > > > > > > > > > > > > > > > > > > > > > = <pathelement location=3D"${test-lib.dir}/my-tests.jar"/> > > > > > > > > > > > > > > > > > > > > > > > = <path refid=3D"project.classpath"/> > > > > > > > > > > > > > > > > > > > > > > > </cla= sspath> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <cont= ainerset> > > > > > > > > > > > > > > > > > > > > > > > = <tomcat4x if=3D"tomcat-dist.dir" > > > > > > > > > > > > > > > > > > > > > > > = dir=3D"${tomcat-dist.dir}" port=3D"${test.port}" > > > > > > > > > > > > > > > > > > > > > > > = output=3D"${test.results}/tomcat4x.out" > > > > > > > > > > > > > > > > > > > > > > > = todir=3D"${test.results}/tomcat4x" > > > > > > > > > > > > > > > > > > > > > > > = tmpdir=3D"${test.temp.dir}" > > > > > > > > > > > > > > > > > > > > > > > = jvmArgs=3D"-DGG_HOME=3DC:/test"/> > > > > > > > > > > > > > > > > > > > > > > > </con= tainerset> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <form= atter type=3D"brief" usefile=3D"false"/> > > > > > > > > > > > > > > > > > > > > > > > <form= atter type=3D"xml"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <batc= htest> > > > > > > > > > > > > > > > > > > > > > > > = <fileset dir=3D"${testsrc.dir}"> > > > > > > > > > > > > > > > > > > > > > > > = <include name=3D"**/Test*.java"/> > > > > > > > > > > > > > > > > > > > > > > > = <exclude name=3D"**/Test*All.java"/> > > > > > > > > > > > > > > > > > > > > > > > = </fileset> > > > > > > > > > > > > > > > > > > > > > > > </bat= chtest> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > </cactus> > > > > > > > > > > > > > > > > > > > > > > > <!-- Generate the JUnit repor= ts --> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <junitreport = todir=3D"${test.results}/tomcat4x"> > > > > > > > > > > > > > > > > > > > > > > > <file= set dir=3D"${test.results}/tomcat4x" > > > > > > > > > > > > > > > > > > > > > > > = includes=3D"TEST-*.xml"/> > > > > > > > > > > > > > > > > > > > > > > > <repo= rt todir=3D"${test.results}/tomcat4x" > > > > > > > > > > > > > > > > > > > > > > > = format=3D"frames"/> > > > > > > > > > > > > > > > > > > > > > > > </junitreport= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <fail if=3D"t= ests.failed">At least one test failed!</fail> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > </target> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <target name=3D"coverage" des= cription=3D"HTML coverage reports can be > > > > > > > > > > > > > > > > > > > > > > > found in build/coverage"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <mkdir dir=3D= "${test.results}/coverage"/> > > > > > > > > > > > > > > > > > > > > > > > <cobertura-re= port srcdir=3D"${src.dir}" > > > > > > > > > > > > > > > > > > > > > > > destdir=3D"${test.results}/co= verage" > > > > > > > > > > > > > > > > > > > > > > > datafile=3D"${test.dir}/cober= tura.ser"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <echo> > > > > > > > > > > > > > > > > > > > > > > > Cober= tura reports have been generated. > > > > > > > > > > > > > > > > > > > > > > > The H= TML report is ${test.results}/coverage/index.html > > > > > > > > > > > > > > > > > > > > > > > </echo> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > </target> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm getting 0% coverage for a= ll tests. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is there a way to see if the = classes have been instrumented? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------= -------------------------- > > > > > > > > > > > > > > > > > > > > > > > SF.Net email is Sponsored by = the Better Software Conference & EXPO > > > > > > > > > > > > > > > > > > > > > > > September 19-22, 2005 * San F= rancisco, CA * Development Lifecycle Practices > > > > > > > > > > > > > > > > > > > > > > > Agile & Plan-Driven Developme= nt * Managing Projects & Teams * Testing & QA > > > > > > > > > > > > > > > > > > > > > > > Security * Process Improvemen= t & Measurement * http://www.sqe.com/bsce5sf > > > > > > > > > > > > > > > > > > > > > > > _____________________________= __________________ > > > > > > > > > > > > > > > > > > > > > > > Cobertura-devel mailing list > > > > > > > > > > > > > > > > > > > > > > > Cob...@li...urcef= orge.net > > > > > > > > > > > > > > > > > > > > > > > https://lists.sourceforge.net= /lists/listinfo/cobertura-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pra= ctices > > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing= & QA > > > Security * Process Improvement & Measurement * http://www.sqe.com/bsc= e5sf > > > _______________________________________________ > > > Cobertura-devel mailing list > > > Cob...@li... > > > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > > > > > |
|
From: Chris D. <chr...@tv...> - 2005-08-25 19:38:48
|
Anyone have some sample ant or maven config settings for Cobertura that excludes a directory of classes from the report? =20 Thanks! =20 --Chris |
|
From: Grzegorz L. <ha...@gm...> - 2005-08-25 19:18:16
|
---------- Forwarded message ---------- From: Grzegorz Lukasik <ha...@gm...> Date: Aug 25, 2005 9:12 PM Subject: Re: [Cobertura-devel] reports not working properly To: yamaduc <ya...@gm...> It seems I have solution for the problem with Tomcat. When you shut down Tomcat using CTRL+C under windows there are no problems with Cobertura (then shutdown hooks - Tomcat's and Coberturas' - are started together), but when you are using shutdown.bat the problem with empty file appears becouse Cobertura shutdown hook is fired after Tomcat finishes all work. This log I found in catalina.out: INFO: Stopping Coyote HTTP/1.1 on http-8081 INFO saveCoverageData, Saving coverage data to D:\work\cactus-test\project\build\cobertura.ser Aug 25, 2005 8:57:00 PM org.apache.catalina.loader.WebappClassLoader loadCl= ass INFO: Illegal access: this web application instance has been stopped already (the eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact) It seems that Cobertura tries to load some class for web application and Tomcat does not allow for it after shutdown. Temporary solution is to _not_ include cobertura.jar (and others) inside war, but put them inside common\lib Tomcat subdirectory. I will check if we can fix this problem so that no such hack will be needed. Grzegorz On 8/25/05, yamaduc <ya...@gm...> wrote: > I added <sleep seconds=3D"42"/> before the report call. > > It's still throwing the EOF Exception. > > I noticed David is having the same issue and he's correct, the > cobertura.ser is empty before. > > On 8/25/05, Grzegorz Lukasik <ha...@gm...> wrote: > > By default JBoss at the end of its shutdown uses > > > > Runtime.getRuntime().halt(0); > > > > so that JVM is forced to halt. If other shutdown hooks are working > > there are terminated - so Cobertura can be terminated in the middle of > > serializing datafile (halt method documentation: > > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html#halt(int= )) > > > > In case of Tomcat it seems that they do not use such brutal methods, > > and Cactus uses standard Tomcat shutdown. But Tomcat shutdown is fired > > from separate thread, maybe cobertura-report is run when Tomcat has > > not finished its shutdown yet? Could you add sleep task before > > launching cobertura-report? Maybe it will help. > > > > Below are presented some technical details and possible solution for > > JBoss users. > > > > Grzegorz > > > > > > -----------------------------------------------------------------------= --------------------------------- > > JBoss ServerImpl.java - source: > > > > http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-system/src/main/org/j= boss/system/server/ServerImpl.java?view=3Dmarkup > > > > Interesting sections: > > > > -------------- ServerImpl.java > > public ShutdownHook(final ObjectName controller, final > > ObjectName mainDeployer) > > { > > ... > > > > String value =3D System.getProperty("jboss.shutdown.forceHalt"= , null); > > if (value !=3D null) { > > forceHalt =3D new Boolean(value).booleanValue(); > > } > > -------------- > > public void run() > > { > > shutdown(); > > > > // later bitch > > if (forceHalt) { > > System.out.println("Halting VM"); > > Runtime.getRuntime().halt(0); > > } > > } > > -------------- > > BTW. Nice comment ;) > > > > -----------------------------------------------------------------------= --------------------------------- > > JBoss changelog: > > > > http://sourceforge.net/project/shownotes.php?release_id=3D97289 > > > > Section: Changes between JBoss_3_0_1RC1 and JBoss_3_0_0 > > > > Added jboss.shutdown.forceHalt system property, which defaults to true. > > This value controls whether or not the shutdown hook will force th= e vm > > to exit after shutdown has been completed. This might help for si= tuations > > where the vm is crazy, locked up in socket io or something... or n= ot. > > > > ------------ > > You can use this option to prevent Runtime.halt use: > > > > run -Djboss.shutdown.forceHalt=3Dfalse > > > > You should see these lines at JBoss shutdown (this lines are written > > on standard output, so won't see them in logs): > > Shutdown complete > > > > When this option is not used additionaly this line is presented: > > Shutdown complete > > Halting VM > > > > NOTICE: I will be able to test it with Cobertura installation on Linux = tomorrow. > > > > > > On 8/24/05, yamaduc <ya...@gm...> wrote: > > > Here's the stack, see below. > > > > > > Thanks for your help. > > > > > > Maybe I can get a thread dump, if that'll help. > > > > > > > > > [cobertura-report] java.io.EOFException > > > [cobertura-report] at > > > java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream= .java:2165) > > > [cobertura-report] at > > > java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputS= tream.java:2631) > > > [cobertura-report] at > > > java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:734= ) > > > [cobertura-report] at > > > java.io.ObjectInputStream.<init>(ObjectInputStream.java:253) > > > [cobertura-report] at > > > net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler.loadCo= verageData(CoverageDataFileHandler.java:97) > > > [cobertura-report] at > > > net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler.loadCo= verageData(CoverageDataFileHandler.java:68) > > > [cobertura-report] at > > > net.sourceforge.cobertura.reporting.Main.parseArguments(Main.java:91) > > > [cobertura-report] at > > > net.sourceforge.cobertura.reporting.Main.main(Main.java:161) > > > > > > > > > > > > On 8/24/05, Grzegorz Lukasik <ha...@gm...> wrote: > > > > Yeah, it looks pretty strange. I have noticed it recently when runn= ing > > > > instrumented application in JBoss. On Windows it worked ok, but und= er > > > > Linux I got EOFException when reporting task was reading cobertura.= ser > > > > - it seems that cobertura.ser was truncated (or maybe not fully > > > > written) during instrumentation. I have no time to investigate it y= et, > > > > but now I see it was no accident, and I will look at it. > > > > > > > > cobertura.ser is written during virtual machine shutdown, maybe som= e > > > > applications that also perfom some actions on VM shutdown use > > > > java.lang.Runtime.halt method at the end? I am not sure. > > > > > > > > Grzegorz > > > > > > > > PS. Eh, I won't be able to do anything today. > > > > > > > > On 8/24/05, yamaduc <ya...@gm...> wrote: > > > > > well, this is strange. > > > > > > > > > > I put all the cobertura jar in the war file. > > > > > > > > > > The classes get instrumented, but during the report, it deletes > > > > > everything in the cobertura.ser > > > > > > > > > > Then an EOF exception is thrown. > > > > > > > > > > On 8/24/05, Grzegorz Lukasik <ha...@gm...> wrote: > > > > > > Hmmmm... I am not sure what is the cause. Have you add cobertur= a.jar > > > > > > and all depended libraries to the war (or to Tomcat's lib direc= tory)? > > > > > > And have you put all classes and other resources that were not > > > > > > instrumented (e.g. interfaces, files with properties) to these > > > > > > instrumented? > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > On 8/24/05, yamaduc <ya...@gm...> wrote: > > > > > > > Cobertura isn't throwing any exception. > > > > > > > If I put the instrumented classes in the war file I get the f= ollowing error. > > > > > > > > > > > > > > [cactus] ----------------------------------------------------= ------------- > > > > > > > [cactus] Running tests against Tomcat 4.1.27 @ http://localho= st:8810 > > > > > > > [cactus] ----------------------------------------------------= ------------- > > > > > > > [cactus] Testsuite: com.goldengate.veridata.struts.actions.Te= stCreateGroupAction > > > > > > > [cactus] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: = 0.63 sec > > > > > > > > > > > > > > [cactus] ------------- Standard Error ----------------- > > > > > > > [cactus] log4j:WARN No appenders could be found for logger > > > > > > > (org.apache.cactus.internal.configuration.ConfigurationInitia= lizer). > > > > > > > [cactus] log4j:WARN Please initialize the log4j system proper= ly. > > > > > > > [cactus] ------------- ---------------- --------------- > > > > > > > [cactus] Testcase: > > > > > > > testExceptionBean(org.apache.cactus.ServletTestCase): Cau= sed an > > > > > > > ERROR > > > > > > > [cactus] Error while initializing ActionServlet: Parsing erro= r > > > > > > > processing resource path /WEB-INF/struts-config.xml > > > > > > > [cactus] junit.framework.AssertionFailedError: Error while > > > > > > > initializing ActionServlet: Parsing error processing resource= path > > > > > > > /WEB-INF/struts-config. > > > > > > > [cactus] at > > > > > > > servletunit.struts.CactusStrutsTestCase.getActionServlet(Cact= usStrutsTestCase.java:486) > > > > > > > [cactus] at > > > > > > > servletunit.struts.CactusStrutsTestCase.actionPerform(CactusS= trutsTestCase.java:536) > > > > > > > [cactus] at > > > > > > > com.goldengate.veridata.struts.actions.TestCreateGroupAction.= testExceptionBean(TestCreateGroupAction.java:63) > > > > > > > [cactus] at > > > > > > > org.apache.cactus.internal.AbstractCactusTestCase.runBareServ= er(AbstractCactusTestCase.java:153) > > > > > > > [cactus] at > > > > > > > org.apache.cactus.internal.server.AbstractWebTestCaller.doTes= t(AbstractWebTestCaller.java:119) > > > > > > > [cactus] at > > > > > > > org.apache.cactus.internal.server.AbstractWebTestController.h= andleRequest_aroundBody0(AbstractWebTestController.java:93) > > > > > > > [cactus] at > > > > > > > org.apache.cactus.internal.server.AbstractWebTestController.h= andleRequest_aroundBody1$advice(AbstractWebTestController.java:217) > > > > > > > [cactus] at > > > > > > > org.apache.cactus.internal.server.AbstractWebTestController.h= andleRequest(AbstractWebTestController.java) > > > > > > > [cactus] at > > > > > > > org.apache.cactus.server.ServletTestRedirector.doPost_aroundB= ody2(ServletTestRedirector.java:101) > > > > > > > [cactus] at > > > > > > > org.apache.cactus.server.ServletTestRedirector.doPost_aroundB= ody3$advice(ServletTestRedirector.java:217) > > > > > > > [cactus] at > > > > > > > org.apache.cactus.server.ServletTestRedirector.doPost(Servlet= TestRedirector.java) > > > > > > > [cactus] at > > > > > > > org.apache.cactus.server.ServletTestRedirector.doGet_aroundBo= dy0(ServletTestRedirector.java:72) > > > > > > > [cactus] at > > > > > > > org.apache.cactus.server.ServletTestRedirector.doGet_aroundBo= dy1$advice(ServletTestRedirector.java:217) > > > > > > > [cactus] at > > > > > > > org.apache.cactus.server.ServletTestRedirector.doGet(ServletT= estRedirector.java) > > > > > > > [cactus] at javax.servlet.http.HttpServlet.service(HttpSe= rvlet.java:740) > > > > > > > [cactus] at javax.servlet.http.HttpServlet.service(HttpSe= rvlet.java:853) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFil= ter(ApplicationFilterChain.java:247) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(Appl= icationFilterChain.java:193) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardWrapperValve.invoke(Standard= WrapperValve.java:256) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardPipeline$StandardPipelineVal= veContext.invokeNext(StandardPipeline.java:643) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipe= line.java:480) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.j= ava:995) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardContextValve.invoke(Standard= ContextValve.java:191) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardPipeline$StandardPipelineVal= veContext.invokeNext(StandardPipeline.java:643) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipe= line.java:480) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.j= ava:995) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardContext.invoke(StandardConte= xt.java:2416) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHos= tValve.java:180) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardPipeline$StandardPipelineVal= veContext.invokeNext(StandardPipeline.java:643) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorD= ispatcherValve.java:171) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardPipeline$StandardPipelineVal= veContext.invokeNext(StandardPipeline.java:641) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepor= tValve.java:172) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardPipeline$StandardPipelineVal= veContext.invokeNext(StandardPipeline.java:641) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipe= line.java:480) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.j= ava:995) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardE= ngineValve.java:174) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardPipeline$StandardPipelineVal= veContext.invokeNext(StandardPipeline.java:643) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipe= line.java:480) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.j= ava:995) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.connector.http.HttpProcessor.process(Http= Processor.java:1040) > > > > > > > [cactus] at > > > > > > > org.apache.catalina.connector.http.HttpProcessor.run(HttpProc= essor.java:1151) > > > > > > > [cactus] at java.lang.Thread.run(Thread.java:534) > > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote: > > > > > > > > Try to run ant with -v option, there should be stack trace = with more detail. > > > > > > > > Did you put only instrumented classes into war? If Cobertur= a does not > > > > > > > > instrument class for some reason (e.g. for interface) it do= es not put > > > > > > > > uninstrumented file among instrumented. Maybe some interfac= e is > > > > > > > > missing? (You should copy all remaining files to the war). > > > > > > > > > > > > > > > > Or maybe Cobertura library is not in Tomcat libs? > > > > > > > > > > > > > > > > I am just guessing. > > > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > > PS. I am going sleep, so I won't be able to answer today. > > > > > > > > > > > > > > > > On 8/24/05, yamaduc <ya...@gm...> wrote: > > > > > > > > > Here's what happens when i put the instrumented classes i= n the war file. > > > > > > > > > > > > > > > > > > [cactus] Testcase: > > > > > > > > > testExceptionBean(org.apache.cactus.ServletTestCase): = Caused an > > > > > > > > > ERROR > > > > > > > > > [cactus] Error while initializing ActionServlet: Parsing = error > > > > > > > > > processing resource path /WEB-INF/struts-config.xml > > > > > > > > > [cactus] junit.framework.AssertionFailedError: Error whil= e > > > > > > > > > initializing ActionServlet: Parsing error processing reso= urce path > > > > > > > > > /WEB-INF/struts-config.xml > > > > > > > > > > > > > > > > > > I tried it without the instrumented classes in the war fi= le and this > > > > > > > > > message does not appear. > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote: > > > > > > > > > > If you put insturmented classes in serverclasses dir fo= r Weblogic, > > > > > > > > > > then they were treaten as part of web application. > > > > > > > > > > > > > > > > > > > > You can try (at least for test) to instrument war - it = should be > > > > > > > > > > possible from Cobertura 1.5. Be aware that you will nee= d cobertura.jar > > > > > > > > > > (and dependend) in some tomcat lib subdirectory (or you= can pack it > > > > > > > > > > into war). > > > > > > > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote: > > > > > > > > > > > I had this working before with weblogic just fine. > > > > > > > > > > > > > > > > > > > > > > I'm using tomcat now. > > > > > > > > > > > > > > > > > > > > > > With weblogic, i didn't need to put the instrumented = classes in the > > > > > > > > > > > war/ear file. > > > > > > > > > > > > > > > > > > > > > > I put the instrumented classes in the server's classp= ath and it worked fine. > > > > > > > > > > > > > > > > > > > > > > I'll try to put them in the war and see what happens. > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrot= e: > > > > > > > > > > > > Correct me if I'm wrong, cactus task work this way: > > > > > > > > > > > > > > > > > > > > > > > > - deploy war inside application container > > > > > > > > > > > > - run tests on deployed application by cactus > > > > > > > > > > > > > > > > > > > > > > > > So if I get it right, classes packed into war are u= sed when performing > > > > > > > > > > > > tests. When you specifiy classpath inside cactus ta= sk, it specifies > > > > > > > > > > > > classpath for test classes. So you need insturmente= d classes packed > > > > > > > > > > > > into war, so that they are run during tests. > > > > > > > > > > > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote: > > > > > > > > > > > > > so i should have the instrumented classes instead= of the standard classes? > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> = wrote: > > > > > > > > > > > > > > One more hit, maybe in created war you do not h= ave instrumented classes? > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote: > > > > > > > > > > > > > > > The date never changes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <hauserx@gmail.c= om> wrote: > > > > > > > > > > > > > > > > Yes, it should be updated when tests are ru= n but size will be the > > > > > > > > > > > > > > > > same. Check file change date. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reports does not update cobertura.ser. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wro= te: > > > > > > > > > > > > > > > > > Is the cobertura.ser supposed to update d= uring the report process? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I watched it after instrumentation, its 6= 91k. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > After my tests run and the reports are ex= ecuted, it's still the same 691k. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> w= rote: > > > > > > > > > > > > > > > > > > Well, I tried passing it in as a runtim= e paramter to the jvm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then the report task complained, couldn= 't find cobertura.ser. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, I added datafile to the ant task an= d the error message went away, > > > > > > > > > > > > > > > > > > see ant target below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I only have one .ser file. > > > > > > > > > > > > > > > > > > <cobertura-instrument datafile=3D"${tes= t.dir}/cobertura.ser" > > > > > > > > > > > > > > > > > > todir=3D"${instrumented.classes}"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <target name=3D"coverage" descr= iption=3D"HTML coverage reports can be > > > > > > > > > > > > > > > > > > found in build/coverage"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <mkdir dir=3D"${test.re= sults}/coverage"/> > > > > > > > > > > > > > > > > > > <cobertura-report srcdi= r=3D"${src.dir}" > > > > > > > > > > > > > > > > > > destdir=3D"${test.results}/coverage" > > > > > > > > > > > > > > > > > > datafile=3D"${test.dir}/cobertura.ser"/= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <echo> > > > > > > > > > > > > > > > > > > Cobertura repor= ts have been generated. > > > > > > > > > > > > > > > > > > The HTML report= is ${test.results}/coverage/index.html > > > > > > > > > > > > > > > > > > </echo> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > </target> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <hauserx@g= mail.com> wrote: > > > > > > > > > > > > > > > > > > > Hey, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You probably do not set property net.= sourceforge.cobertura.datafile > > > > > > > > > > > > > > > > > > > when running tests (I do not know how= to do it inside cactus task). Do > > > > > > > > > > > > > > > > > > > you get additional cobertura.ser in d= irectory where tests are run? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...= m> wrote: > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have the following build script. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <target name=3D"instrument" depends= =3D"compile" description=3D"Add Cobertura > > > > > > > > > > > > > > > > > > > > instrumentation"> > > > > > > > > > > > > > > > > > > > > <!-- instrument the= application classes, writing the instrumented > > > > > > > > > > > > > > > > > > > > classes into ${instrumented.classes= }. --> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <cobertura-instrume= nt datafile=3D"${test.dir}/cobertura.ser" > > > > > > > > > > > > > > > > > > > > todir=3D"${instrumented.classes}"> > > > > > > > > > > > > > > > > > > > > <!-- Note t= hat the following line causes instrument to ignore any > > > > > > > > > > > > > > > > > > > > source= line containing a reference to log4j, for the purposes > > > > > > > > > > > > > > > > > > > > of= coverage reporting. --> > > > > > > > > > > > > > > > > > > > > <ignore reg= ex=3D"org.apache.log4j.*"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <fileset di= r=3D"${classes.dir}"> > > > > > > > > > > > > > > > > > > > > <!-= - instrument all the application classes, but don't instrument > > > > > > > > > > > > > > > > > > > > the test classes. --> > > > > > > > > > > > > > > > > > > > > <in= clude name=3D"**/*.class"/> > > > > > > > > > > > > > > > > > > > > <ex= clude name=3D"**/*Test.class"/> > > > > > > > > > > > > > > > > > > > > </fileset> > > > > > > > > > > > > > > > > > > > > </cobertura-instrum= ent> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > </target> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <target name=3D"test" depends=3D"pr= epare.test.package" description=3D"Run > > > > > > > > > > > > > > > > > > > > the tests on the defined container"= > > > > > > > > > > > > > > > > > > > > > <!-- Run the tests = --> > > > > > > > > > > > > > > > > > > > > <mkdir dir=3D"${tes= t.results}/tomcat4x"/> > > > > > > > > > > > > > > > > > > > > <cactus warfile=3D"= ${test-war.dir}/${app.name}-${app.version}.war" > > > > > > > > > > > > > > > > > > > > fork=3D"yes" failureproperty=3D"tes= ts.failed" haltonerror=3D"true"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <!-- Config= ure the cactus task for logging --> > > > > > > > > > > > > > > > > > > > > <cactusprop= erty server=3D"false" > > > > > > > > > > > > > > > > > > > > pro= pertiesFile=3D"${meta.dir}/${configtype}/test/logging_client.properties"/> > > > > > > > > > > > > > > > > > > > > <cactusprop= erty server=3D"true" > > > > > > > > > > > > > > > > > > > > pro= pertiesFile=3D"${meta.dir}/${configtype}/test/logging_server.properties"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <!-- Additi= onal jars that will be added to the classpath used to start the > > > > > > > > > > > > > > > > > > > > co= ntainer (in addition to the container jars themseleves which are > > > > > > > > > > > > > > > > > > > > au= tomatically added by the <cactus> task --> > > > > > > > > > > > > > > > > > > > > <containerc= lasspath> > > > > > > > > > > > > > > > > > > > > <pa= thelement path=3D"${test-props.dir}"/> > > > > > > > > > > > > > > > > > > > > </container= classpath> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <classpath> > > > > > > > > > > > > > > > > > > > > <pa= thelement path=3D"${instrumented.classes}"/> > > > > > > > > > > > > > > > > > > > > <pa= thelement path=3D"${classes.dir}"/> > > > > > > > > > > > > > > > > > > > > <pa= thelement location=3D"${test-lib.dir}/my-tests.jar"/> > > > > > > > > > > > > > > > > > > > > <pa= th refid=3D"project.classpath"/> > > > > > > > > > > > > > > > > > > > > </classpath= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <containers= et> > > > > > > > > > > > > > > > > > > > > <to= mcat4x if=3D"tomcat-dist.dir" > > > > > > > > > > > > > > > > > > > > = dir=3D"${tomcat-dist.dir}" port=3D"${test.port}" > > > > > > > > > > > > > > > > > > > > = output=3D"${test.results}/tomcat4x.out" > > > > > > > > > > > > > > > > > > > > = todir=3D"${test.results}/tomcat4x" > > > > > > > > > > > > > > > > > > > > = tmpdir=3D"${test.temp.dir}" > > > > > > > > > > > > > > > > > > > > = jvmArgs=3D"-DGG_HOME=3DC:/test"/> > > > > > > > > > > > > > > > > > > > > </container= set> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <formatter = type=3D"brief" usefile=3D"false"/> > > > > > > > > > > > > > > > > > > > > <formatter = type=3D"xml"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <batchtest> > > > > > > > > > > > > > > > > > > > > <fi= leset dir=3D"${testsrc.dir}"> > > > > > > > > > > > > > > > > > > > > = <include name=3D"**/Test*.java"/> > > > > > > > > > > > > > > > > > > > > = <exclude name=3D"**/Test*All.java"/> > > > > > > > > > > > > > > > > > > > > </f= ileset> > > > > > > > > > > > > > > > > > > > > </batchtest= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > </cactus> > > > > > > > > > > > > > > > > > > > > <!-- Generate the JUnit reports --> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <junitreport todir= =3D"${test.results}/tomcat4x"> > > > > > > > > > > > > > > > > > > > > <fileset di= r=3D"${test.results}/tomcat4x" > > > > > > > > > > > > > > > > > > > > = includes=3D"TEST-*.xml"/> > > > > > > > > > > > > > > > > > > > > <report tod= ir=3D"${test.results}/tomcat4x" > > > > > > > > > > > > > > > > > > > > = format=3D"frames"/> > > > > > > > > > > > > > > > > > > > > </junitreport> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <fail if=3D"tests.f= ailed">At least one test failed!</fail> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > </target> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <target name=3D"coverage" descripti= on=3D"HTML coverage reports can be > > > > > > > > > > > > > > > > > > > > found in build/coverage"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <mkdir dir=3D"${tes= t.results}/coverage"/> > > > > > > > > > > > > > > > > > > > > <cobertura-report s= rcdir=3D"${src.dir}" > > > > > > > > > > > > > > > > > > > > destdir=3D"${test.results}/coverage= " > > > > > > > > > > > > > > > > > > > > datafile=3D"${test.dir}/cobertura.s= er"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <echo> > > > > > > > > > > > > > > > > > > > > Cobertura r= eports have been generated. > > > > > > > > > > > > > > > > > > > > The HTML re= port is ${test.results}/coverage/index.html > > > > > > > > > > > > > > > > > > > > </echo> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > </target> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm getting 0% coverage for all tes= ts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is there a way to see if the classe= s have been instrumented? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------= -------------------- > > > > > > > > > > > > > > > > > > > > SF.Net email is Sponsored by the Be= tter Software Conference & EXPO > > > > > > > > > > > > > > > > > > > > September 19-22, 2005 * San Francis= co, CA * Development Lifecycle Practices > > > > > > > > > > > > > > > > > > > > Agile & Plan-Driven Development * M= anaging Projects & Teams * Testing & QA > > > > > > > > > > > > > > > > > > > > Security * Process Improvement & Me= asurement * http://www.sqe.com/bsce5sf > > > > > > > > > > > > > > > > > > > > ___________________________________= ____________ > > > > > > > > > > > > > > > > > > > > Cobertura-devel mailing list > > > > > > > > > > > > > > > > > > > > Cob...@li...urceforge.n= et > > > > > > > > > > > > > > > > > > > > https://lists.sourceforge.net/lists= /listinfo/cobertura-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
|
From: Mark D. <Mar...@sa...> - 2005-08-25 18:27:56
|
> -----Original Message-----
> From: cob...@li...=20
> [mailto:cob...@li...] On=20
> Behalf Of Matt Kurjanowicz
>=20
> ...
> <cobertura-instrument datafile=3D"${coverage.datafile}"
> todir=3D"${instrumented.classes.dir}">
> <fileset dir=3D"${classes.dir}">
> <exclude name=3D"**/*Test.class" />
> <include name=3D"**/*.class" />
> </fileset>
> </cobertura-instrument>
> ...
Is the order of the includes and excludes important? I've always =
included **/*.class first and then excluded **/*Test.class second.
-Mark
|
|
From: Carlos S. <ca...@ap...> - 2005-08-25 17:09:47
|
Thanks for noticing the typo. I didn't use the plugin lately, so I wouldn't like to release it without testing, but if some users test latest cvs version and say it's ok I will cut a new release. Regards. On 8/25/05, Elliotte Harold <el...@me...> wrote: > Carlos Sanchez wrote: > > It's not automatic, and won't probably be. The plugin can be improved > > to allow overriding it as it is the clover plugin IIRC. I've upgraded > > the plugin in CVS to use cobertura 1.6 and I've uploaded the cobertura > > 1.6 jar to ibiblio, so in a few hours you should be able to build it > > from CVS. >=20 > Thanks. Will the plugin itself be updated anytime soon? >=20 >=20 > > Any help in mantaining and improving the plugin is appreciated. > > http://maven-plugins.sourceforge.net/maven-cobertura-plugin/. >=20 > Well I don't know a lot about jelly, but here's one fix. In your > project.xml, you depend on javancss twice: >=20 > <dependency> > <groupId>urbanophile</groupId> > <artifactId>java-getopt</artifactId> > <version>1.0.9</version> > <url>http://www.urbanophile.com/arenn/hacking/download.html</url> > </dependency> > <dependency> > <groupId>javancss</groupId> > <artifactId>javancss</artifactId> > <version>21.41</version> > <url>http://www.kclee.de/clemens/java/javancss/</url> > </dependency> > <dependency> > <groupId>javancss</groupId> > <artifactId>ccl</artifactId> > <version>21.41</version> > <url>http://www.kclee.de/clemens/java/javancss/</url> > </dependency> > </dependencies> >=20 > I suspect this could be changed to just >=20 > <dependency> > <groupId>urbanophile</groupId> > <artifactId>java-getopt</artifactId> > <version>1.0.9</version> > <url>http://www.urbanophile.com/arenn/hacking/download.html</url> > </dependency> > <dependency> > <groupId>javancss</groupId> > <artifactId>javancss</artifactId> > <version>21.41</version> > <url>http://www.kclee.de/clemens/java/javancss/</url> > </dependency> > </dependencies> >=20 > -- > Elliotte Rusty Harold el...@me... > XML in a Nutshell 3rd Edition Just Published! > http://www.cafeconleche.org/books/xian3/ > http://www.amazon.com/exec/obidos/ISBN=3D0596007647/cafeaulaitA/ref=3Dnos= im > |
|
From: David T. <sy...@sy...> - 2005-08-25 16:25:54
|
I am having problems with Cobertura and Cactus. I think this problem was mentioned by yamaduc. Basically, after my Cactus tests run (and they run fine) Cactus shuts down Tomcat and my cobertura.ser file is suddenly empty. Has anyone figured out any kind of solution for this yet? In one thread ( https://sourceforge.net/mailarchive/message.php?msg_id=12756263 ) Grzegorz said something about adding a sleep task before launching cobertura-report, but by the time I run cobertura-report, the cobertura.ser is already empty... Is there something else I can try? |
|
From: David P. <dpu...@ep...> - 2005-08-25 15:57:09
|
It looks like you already are excluding those files, so you may need to
diagnose your ant script to find out why they're still showing up.
One possibility is that you ran your coverage, saw the *Test files, then
added the exclude. Then looking at the reports you still see them. If
that's the case, consider deleting the cobertura.ser file then
re-running your tests and see if they're still there. In my script the
.ser file is deleted before instrumentation, so that way I know I'm
getting a fresh set of data.
I'm knew to this though so hopefully someone more experienced can
correct me if this isn't good advice.
d
Matt Kurjanowicz wrote:
> Hello,
> Sorry for the frequent emails, but I'm new to Cobertura. I've gotten
> cobertura to work to generate coverage reports, but those reports
> contain the actual test classes, not just the classes that are being
> tested. I was wondering if there is any way to exclude those classes
> from the report?
> <target name="coverage-reports"
> depends="compile-all,prepare"
> description="Generate unit test coverage reports.">
>
> <echo message="Coverage Datafile = ${coverage.datafile}" />
> <cobertura-instrument datafile="${coverage.datafile}"
> todir="${instrumented.classes.dir}">
> <fileset dir="${classes.dir}">
> <exclude name="**/*Test.class" />
> <include name="**/*.class" />
> </fileset>
> </cobertura-instrument>
>
> <!-- Write our own JUnit task so that its settings work with
> cobertura. -->
> <junit fork="yes">
> <sysproperty key="net.sourceforge.cobertura.datafile"
> value="${coverage.datafile}" />
> <classpath location="${instrumented.classes.dir}" />
> <classpath refid="application.classpath" />
>
> <formatter type="brief" usefile="false" />
>
> <batchtest>
> <fileset dir="${instrumented.classes.dir}">
> <include name="**/*Test.class" />
> </fileset>
> </batchtest>
> </junit>
>
> <cobertura-report srcdir="${src.dir}"
> destdir="${coverage.report.dir}"
> datafile="${coverage.datafile}" />
> </target>
>
> TIA,
> Matt Kurjanowicz
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
|
89 messages has been excluded from this view by a project administrator.
