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: Piotr T. <pi...@ta...> - 2010-10-07 22:04:40
|
ThreadSafeRigorous is set to off, because I assume that most of users want to have 4 times faster execution of tests and exact results of coverage (in multi thread programs too) instead of 4 times slower code execution and exact counts of hits per line. If we use System.out to log messages, we should consider changing it java logging. This way it could be configured by java properties. Piotr 2010/10/7 Steven Christou <ste...@re...> > This is great! I ran all my tests, and it looks like this fix is going to > be a nice one. I was just wondering though if you could provide another jar > without the calls to System.out. Also I was wondering is ThreadSafeRigorous > set to OFF by default? > > Thanks again! > > > On 10/4/2010 3:01 AM, Piotr Tabor wrote: > > If you want to test the RC version from the branch, I've prepared the ready > jar for it: > http://www.mimuw.edu.pl/~ptab/Cobertura/cobertura-1.10.0-2010.10-ptab.jar<http://www.mimuw.edu.pl/%7Eptab/Cobertura/cobertura-1.10.0-2010.10-ptab.jar> > . > > Piotr Tabor > > On Sun, Oct 3, 2010 at 11:14 PM, Piotr Tabor <pi...@ta...> wrote: > >> The last publicly available version 1.9.4.1 does not support this options >> (--ignoreTrivial, --ignoreMethodAnnotation). Trunk (with content planned of >> 1.9.5) and ptab_v2_0 branch (with proposition probably for 1.10.0) >> contains support for this options (description here: >> https://cobertura.svn.sourceforge.net/svnroot/cobertura/trunk/cobertura/ChangeLog). >> Documentation has not been updated because this changes has not been >> released yet. >> >> End - yes: all this options are supported by ant-task. >> >> Regards, >> Piotr Tabor >> >> >> 210/9/29 Steven Christou <ste...@re...> >> >> I was wondering if there was going to be any documentation added to the >>> cobertura documentation page about these new arguments. Also I was wondering >>> if there was any support for these arguments through the ant task? >>> Thanks! >>> >>> >>> On 9/26/2010 4:46 PM, Piotr Tabor wrote: >>> >>> I've worked on version in the brunch. The code is AFAIK >>> test-before-release ready. >>> I've migrated support for --ignoreTrivial and --ignoreAnnotations and >>> added a new switch --threadsafeRigorous. In the mode cobertura is less >>> faster then without >>> the switch, but the counts of hits per line are precise in multithreaded >>> situations. The switch should not affect the coverage results (% of hit >>> lines and branches). >>> >>> My spare time is going to be over, so I don't plan any other changes then >>> bugfixes to the reported problems with the new solution. >>> >>> Piotr Tabor >>> >>> On Mon, Sep 13, 2010 at 8:14 PM, John W. Lewis <Joh...@sa...>wrote: >>> >>>> >>>> >>> I’ll take a look – hopefully soon. >>>> >>>> >>>> >>>> *From:* Piotr Tabor [mailto:pio...@gm...] >>>> *Sent:* Sunday, September 12, 2010 3:59 AM >>>> *To:* cob...@li... >>>> *Subject:* [Cobertura-devel] Major 'instrumentation code' refactoring >>>> >>>> >>>> >>>> Hello Cobertura masters, >>>> >>>> Long time ago (March) I promised to provide a really faster version of >>>> Cobertura, but I started to be really busy then. Finally I found some time >>>> and prepared it. >>>> It is stored here: >>>> https://cobertura.svn.sourceforge.net/svnroot/cobertura/branches/ptab_v2_0 >>>> (should be probably 1.10) and the net.sourceforge.cobertura.instrument >>>> package >>>> is totally rewritten. >>>> >>>> The current status is: >>>> >>>> Additional benefits: >>>> * Speed, speed, speed >>>> * It is extremly close to supress requirement that *.sar file >>>> created during instrumentation is needed during runtime. In fact the file is >>>> now created >>>> only for backward compability. >>>> * SwitchFunctionalTest works now. Some simillar fixes to coverage >>>> in other areas. >>>> * I think that the new code is cleaner. >>>> >>>> Drawbacks: >>>> * To count the hits I'm using in this implementation just: int[] >>>> hits; >>>> and to register hit I use: hits[...]++; >>>> It is extremly fast, but not exactly thread safe. There will be >>>> no 'exception' thrown or other problems, but we can >>>> miss some hits (tests shows that it is <5% of hits). But it is >>>> guaranteed that if there is at least one hit for a single touch-point, it >>>> will be >>>> registered. So it does not affect coverage, and seams to be >>>> acceptable for 99.9% usage scenarios. >>>> If required an exact-thread-safe mode can be implemented (see >>>> AtomicArrayCodeProvider) >>>> (but usege of AtomicIntegerArray causes significant (5-10 times) >>>> performance decrease - but still is faster then cobertura 1.9.4+). >>>> >>>> TODO: >>>> * ignore and ignore trival functionality has not been merged yet >>>> * exact-thread-safe mode swotch >>>> * The code need more tests >>>> >>>> I would appreciate if you (John ?) could have a look at the code and >>>> scribe opinion about it. >>>> >>>> Regards, >>>> Piotr Tabor >>>> >>> >>> >>> >>> -- >>> Pozdrawiam, >>> Piotr Tabor >>> >>> >>> ------------------------------------------------------------------------------ >>> Start uncovering the many advantages of virtual appliances >>> and start using them to simplify application deployment and >>> accelerate your shift to cloud computing.http://p.sf.net/sfu/novell-sfdev2dev >>> >>> >>> _______________________________________________ >>> Cobertura-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/cobertura-devel >>> >>> Email Disclaimer:http://www.redprairie.com/emaildisclaimer/ >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Start uncovering the many advantages of virtual appliances >>> and start using them to simplify application deployment and >>> accelerate your shift to cloud computing. >>> http://p.sf.net/sfu/novell-sfdev2dev >>> _______________________________________________ >>> Cobertura-devel mailing list >>> Cob...@li... >>> https://lists.sourceforge.net/lists/listinfo/cobertura-devel >>> >>> >> >> >> -- >> Pozdrawiam, >> Piotr Tabor >> > > > > -- > Pozdrawiam, > Piotr Tabor > > > ------------------------------------------------------------------------------ > Virtualization is moving to the mainstream and overtaking non-virtualized > environment for deploying applications. Does it make network security > easier or more difficult to achieve? Read this whitepaper to separate the > two and get a better understanding.http://p.sf.net/sfu/hp-phase2-d2d > > > _______________________________________________ > Cobertura-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > Email Disclaimer:http://www.redprairie.com/emaildisclaimer/ > > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > -- Pozdrawiam, Piotr Tabor -- Pozdrawiam, Piotr Tabor |
|
From: Steven C. <ste...@re...> - 2010-10-07 16:00:02
|
This is great! I ran all my tests, and it looks like this fix is going to be a nice one. I was just wondering though if you could provide another jar without the calls to System.out. Also I was wondering is ThreadSafeRigorous set to OFF by default? Thanks again! On 10/4/2010 3:01 AM, Piotr Tabor wrote: > If you want to test the RC version from the branch, I've prepared the > ready jar for it: > http://www.mimuw.edu.pl/~ptab/Cobertura/cobertura-1.10.0-2010.10-ptab.jar > <http://www.mimuw.edu.pl/%7Eptab/Cobertura/cobertura-1.10.0-2010.10-ptab.jar>. > > Piotr Tabor > > On Sun, Oct 3, 2010 at 11:14 PM, Piotr Tabor <pi...@ta... > <mailto:pi...@ta...>> wrote: > > The last publicly available version 1.9.4.1 does not support this > options (--ignoreTrivial, --ignoreMethodAnnotation). Trunk (with > content planned of 1.9.5) and ptab_v2_0 branch (with proposition > probably for 1.10.0) > contains support for this options (description here: > https://cobertura.svn.sourceforge.net/svnroot/cobertura/trunk/cobertura/ChangeLog). > Documentation has not been updated because this changes has not > been released yet. > > End - yes: all this options are supported by ant-task. > > Regards, > Piotr Tabor > > > 210/9/29 Steven Christou <ste...@re... > <mailto:ste...@re...>> > > I was wondering if there was going to be any documentation > added to the cobertura documentation page about these new > arguments. Also I was wondering if there was any support for > these arguments through the ant task? > Thanks! > > > On 9/26/2010 4:46 PM, Piotr Tabor wrote: >> I've worked on version in the brunch. The code is AFAIK >> test-before-release ready. >> I've migrated support for --ignoreTrivial and >> --ignoreAnnotations and >> added a new switch --threadsafeRigorous. In the mode >> cobertura is less faster then without >> the switch, but the counts of hits per line are precise in >> multithreaded situations. The switch should not affect the >> coverage results (% of hit lines and branches). >> >> My spare time is going to be over, so I don't plan any other >> changes then bugfixes to the reported problems with the new >> solution. >> >> Piotr Tabor >> >> On Mon, Sep 13, 2010 at 8:14 PM, John W. Lewis >> <Joh...@sa... <mailto:Joh...@sa...>> wrote: >> >> >> I’ll take a look – hopefully soon. >> >> *From:* Piotr Tabor [mailto:pio...@gm... >> <mailto:pio...@gm...>] >> *Sent:* Sunday, September 12, 2010 3:59 AM >> *To:* cob...@li... >> <mailto:cob...@li...> >> *Subject:* [Cobertura-devel] Major 'instrumentation code' >> refactoring >> >> Hello Cobertura masters, >> >> Long time ago (March) I promised to provide a really >> faster version of Cobertura, but I started to be really >> busy then. Finally I found some time and prepared it. >> It is stored here: >> https://cobertura.svn.sourceforge.net/svnroot/cobertura/branches/ptab_v2_0 >> (should be probably 1.10) and the >> net.sourceforge.cobertura.instrument package >> is totally rewritten. >> >> The current status is: >> >> Additional benefits: >> * Speed, speed, speed >> * It is extremly close to supress requirement that >> *.sar file created during instrumentation is needed >> during runtime. In fact the file is now created >> only for backward compability. >> * SwitchFunctionalTest works now. Some simillar >> fixes to coverage in other areas. >> * I think that the new code is cleaner. >> >> Drawbacks: >> * To count the hits I'm using in this implementation >> just: int[] hits; >> and to register hit I use: hits[...]++; >> It is extremly fast, but not exactly thread safe. >> There will be no 'exception' thrown or other problems, >> but we can >> miss some hits (tests shows that it is <5% of >> hits). But it is guaranteed that if there is at least one >> hit for a single touch-point, it will be >> registered. So it does not affect coverage, and >> seams to be acceptable for 99.9% usage scenarios. >> If required an exact-thread-safe mode can be >> implemented (see AtomicArrayCodeProvider) >> (but usege of AtomicIntegerArray causes >> significant (5-10 times) performance decrease - but still >> is faster then cobertura 1.9.4+). >> >> TODO: >> * ignore and ignore trival functionality has not >> been merged yet >> * exact-thread-safe mode swotch >> * The code need more tests >> >> I would appreciate if you (John ?) could have a look at >> the code and scribe opinion about it. >> >> Regards, >> Piotr Tabor >> >> >> >> >> -- >> Pozdrawiam, >> Piotr Tabor >> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> >> >> _______________________________________________ >> Cobertura-devel mailing list >> Cob...@li... <mailto:Cob...@li...> >> https://lists.sourceforge.net/lists/listinfo/cobertura-devel > Email Disclaimer: > http://www.redprairie.com/emaildisclaimer/ > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > <mailto:Cob...@li...> > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > > > > -- > Pozdrawiam, > Piotr Tabor > > > > > -- > Pozdrawiam, > Piotr Tabor > > > ------------------------------------------------------------------------------ > Virtualization is moving to the mainstream and overtaking non-virtualized > environment for deploying applications. Does it make network security > easier or more difficult to achieve? Read this whitepaper to separate the > two and get a better understanding. > http://p.sf.net/sfu/hp-phase2-d2d > > > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel Email Disclaimer: http://www.redprairie.com/emaildisclaimer/ |
|
From: Piotr T. <pi...@ta...> - 2010-10-04 08:01:48
|
If you want to test the RC version from the branch, I've prepared the ready jar for it: http://www.mimuw.edu.pl/~ptab/Cobertura/cobertura-1.10.0-2010.10-ptab.jar. Piotr Tabor On Sun, Oct 3, 2010 at 11:14 PM, Piotr Tabor <pi...@ta...> wrote: > The last publicly available version 1.9.4.1 does not support this options > (--ignoreTrivial, --ignoreMethodAnnotation). Trunk (with content planned of > 1.9.5) and ptab_v2_0 branch (with proposition probably for 1.10.0) > contains support for this options (description here: > https://cobertura.svn.sourceforge.net/svnroot/cobertura/trunk/cobertura/ChangeLog). > Documentation has not been updated because this changes has not been > released yet. > > End - yes: all this options are supported by ant-task. > > Regards, > Piotr Tabor > > > 210/9/29 Steven Christou <ste...@re...> > > I was wondering if there was going to be any documentation added to the >> cobertura documentation page about these new arguments. Also I was wondering >> if there was any support for these arguments through the ant task? >> Thanks! >> >> >> On 9/26/2010 4:46 PM, Piotr Tabor wrote: >> >> I've worked on version in the brunch. The code is AFAIK >> test-before-release ready. >> I've migrated support for --ignoreTrivial and --ignoreAnnotations and >> added a new switch --threadsafeRigorous. In the mode cobertura is less >> faster then without >> the switch, but the counts of hits per line are precise in multithreaded >> situations. The switch should not affect the coverage results (% of hit >> lines and branches). >> >> My spare time is going to be over, so I don't plan any other changes then >> bugfixes to the reported problems with the new solution. >> >> Piotr Tabor >> >> On Mon, Sep 13, 2010 at 8:14 PM, John W. Lewis <Joh...@sa...>wrote: >> >>> >>> >> I’ll take a look – hopefully soon. >>> >>> >>> >>> *From:* Piotr Tabor [mailto:pio...@gm...] >>> *Sent:* Sunday, September 12, 2010 3:59 AM >>> *To:* cob...@li... >>> *Subject:* [Cobertura-devel] Major 'instrumentation code' refactoring >>> >>> >>> >>> Hello Cobertura masters, >>> >>> Long time ago (March) I promised to provide a really faster version of >>> Cobertura, but I started to be really busy then. Finally I found some time >>> and prepared it. >>> It is stored here: >>> https://cobertura.svn.sourceforge.net/svnroot/cobertura/branches/ptab_v2_0 >>> (should be probably 1.10) and the net.sourceforge.cobertura.instrument >>> package >>> is totally rewritten. >>> >>> The current status is: >>> >>> Additional benefits: >>> * Speed, speed, speed >>> * It is extremly close to supress requirement that *.sar file >>> created during instrumentation is needed during runtime. In fact the file is >>> now created >>> only for backward compability. >>> * SwitchFunctionalTest works now. Some simillar fixes to coverage in >>> other areas. >>> * I think that the new code is cleaner. >>> >>> Drawbacks: >>> * To count the hits I'm using in this implementation just: int[] >>> hits; >>> and to register hit I use: hits[...]++; >>> It is extremly fast, but not exactly thread safe. There will be no >>> 'exception' thrown or other problems, but we can >>> miss some hits (tests shows that it is <5% of hits). But it is >>> guaranteed that if there is at least one hit for a single touch-point, it >>> will be >>> registered. So it does not affect coverage, and seams to be >>> acceptable for 99.9% usage scenarios. >>> If required an exact-thread-safe mode can be implemented (see >>> AtomicArrayCodeProvider) >>> (but usege of AtomicIntegerArray causes significant (5-10 times) >>> performance decrease - but still is faster then cobertura 1.9.4+). >>> >>> TODO: >>> * ignore and ignore trival functionality has not been merged yet >>> * exact-thread-safe mode swotch >>> * The code need more tests >>> >>> I would appreciate if you (John ?) could have a look at the code and >>> scribe opinion about it. >>> >>> Regards, >>> Piotr Tabor >>> >> >> >> >> -- >> Pozdrawiam, >> Piotr Tabor >> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing.http://p.sf.net/sfu/novell-sfdev2dev >> >> >> _______________________________________________ >> Cobertura-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/cobertura-devel >> >> Email Disclaimer:http://www.redprairie.com/emaildisclaimer/ >> >> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> Cobertura-devel mailing list >> Cob...@li... >> https://lists.sourceforge.net/lists/listinfo/cobertura-devel >> >> > > > -- > Pozdrawiam, > Piotr Tabor > -- Pozdrawiam, Piotr Tabor |
|
From: Julia N. <Jul...@am...> - 2010-10-03 07:31:34
|
Hi all, I still have a problem with Spring-based Junit tests for JPA persistence modules. I found an archived thread about my problem – see below. I am looking for a patch for it – is there such a patch? Thanks a lot in advance, Julia Re: [Cobertura-devel] cobertura.ser file disappear and regenerated after tests running for a while From: John W. Lewis <JohnW.Lewis@sa...> - 2009-07-15 19:23 Understood. I plan on getting it in. I'd like to create a test for it first. -----Original Message----- From: Ed Randall [mailto:ed_...@ya...<mailto:ed_...@ya...>] Sent: Wednesday, July 15, 2009 2:32 PM To: John W. Lewis Cc: cob...@li...<mailto:cob...@li...> Subject: RE: [Cobertura-devel] cobertura.ser file disappear and regenerated after tests running for a while John, The thing is, we have a lot of Spring-based Junit tests, and Spring does some nasty stuff with classloaders to cache its "context" in a manner that defeats some of the the class unload/reload techniques used by Junit to isolate the tests from one another. We are stuck with those two packages battling it out with their classloaders, AND some of our tests are for JPA persistence modules running against Hibernate, Toplink and OpenJPA, so we don't have much control of what's going on up in classloader-land... so it would be great if this patch or equivalent could make it in to the next release. Thanks Ed Thank you, Julia Neystadt This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp |
|
From: Piotr J. <pio...@op...> - 2010-10-02 14:06:41
|
Hello, I'm trying to instrument a WAR file in Cobertura so I can gather real-time coverage statistics. The WAR files contains JAR libraries with application modules for which I would like to gather the statistics as well. The Ant task does exactly what I want according to the documentation: "You can specify a classpath and a set of classes to include and exclude, and Cobertura will look through the classpath and only instrument the specified classes. When this method is used, Cobertura will instrument archives inside of archives. For example, if you have a war file which contains a jar file at WEB-INF/lib, Cobertura will extract the war, instrument the classes within the jar, then build a new war containing the instrumented jar." However, I cannot make it work. Could you post a complete example? Thanks, Piotr |
|
From: John W. L. <Joh...@sa...> - 2010-09-30 13:24:35
|
I would first make sure the classes under j2ee/home are instrumented - it sounds like you are calling those the "referenced" classes that are showing 0% coverage. John From: Liang HE [mailto:goa...@gm...] Sent: Thursday, September 30, 2010 4:07 AM To: cob...@li... Subject: Re: [Cobertura-devel] Measure web application with referenced library Hi All, I am new to Cobertura, wonder if cobertura is able to measure referenced-lib. We have a main project, say App.ear, deployed on OC4j app server, and a few projects are packaged and put in shared-lib under j2ee/home. I instrumentd all these projects (classes and jar files), and started the app server. It runs well. Then I access flushCobertura or stop app server to dump coverage information. What is frustrating me is that only classes in main Project were measured and have correct data; the referenced classes are showed 0% coverage. I am quite sure they were accessed. Should I do something particularly to have it work? Thanks, Liang |
|
From: Liang HE <goa...@gm...> - 2010-09-30 08:06:39
|
Hi All, I am new to Cobertura, wonder if cobertura is able to measure referenced-lib. We have a main project, say App.ear, deployed on OC4j app server, and a few projects are packaged and put in shared-lib under j2ee/home. I instrumentd all these projects (classes and jar files), and started the app server. It runs well. Then I access flushCobertura or stop app server to dump coverage information. What is frustrating me is that only classes in main Project were measured and have correct data; the referenced classes are showed 0% coverage. I am quite sure they were accessed. Should I do something particularly to have it work? Thanks, Liang |
|
From: Steven C. <ste...@re...> - 2010-09-29 19:00:32
|
I was wondering if there was going to be any documentation added to the cobertura documentation page about these new arguments. Also I was wondering if there was any support for these arguments through the ant task? Thanks! On 9/26/2010 4:46 PM, Piotr Tabor wrote: > I've worked on version in the brunch. The code is AFAIK > test-before-release ready. > I've migrated support for --ignoreTrivial and --ignoreAnnotations and > added a new switch --threadsafeRigorous. In the mode cobertura is less > faster then without > the switch, but the counts of hits per line are precise in > multithreaded situations. The switch should not affect the coverage > results (% of hit lines and branches). > > My spare time is going to be over, so I don't plan any other changes > then bugfixes to the reported problems with the new solution. > > Piotr Tabor > > On Mon, Sep 13, 2010 at 8:14 PM, John W. Lewis <Joh...@sa... > <mailto:Joh...@sa...>> wrote: > > > I’ll take a look – hopefully soon. > > *From:* Piotr Tabor [mailto:pio...@gm... > <mailto:pio...@gm...>] > *Sent:* Sunday, September 12, 2010 3:59 AM > *To:* cob...@li... > <mailto:cob...@li...> > *Subject:* [Cobertura-devel] Major 'instrumentation code' refactoring > > Hello Cobertura masters, > > Long time ago (March) I promised to provide a really faster > version of Cobertura, but I started to be really busy then. > Finally I found some time and prepared it. > It is stored here: > https://cobertura.svn.sourceforge.net/svnroot/cobertura/branches/ptab_v2_0 > (should be probably 1.10) and the > net.sourceforge.cobertura.instrument package > is totally rewritten. > > The current status is: > > Additional benefits: > * Speed, speed, speed > * It is extremly close to supress requirement that *.sar file > created during instrumentation is needed during runtime. In fact > the file is now created > only for backward compability. > * SwitchFunctionalTest works now. Some simillar fixes to > coverage in other areas. > * I think that the new code is cleaner. > > Drawbacks: > * To count the hits I'm using in this implementation just: > int[] hits; > and to register hit I use: hits[...]++; > It is extremly fast, but not exactly thread safe. There > will be no 'exception' thrown or other problems, but we can > miss some hits (tests shows that it is <5% of hits). But it > is guaranteed that if there is at least one hit for a single > touch-point, it will be > registered. So it does not affect coverage, and seams to be > acceptable for 99.9% usage scenarios. > If required an exact-thread-safe mode can be implemented > (see AtomicArrayCodeProvider) > (but usege of AtomicIntegerArray causes significant (5-10 > times) performance decrease - but still is faster then cobertura > 1.9.4+). > > TODO: > * ignore and ignore trival functionality has not been merged yet > * exact-thread-safe mode swotch > * The code need more tests > > I would appreciate if you (John ?) could have a look at the code > and scribe opinion about it. > > Regards, > Piotr Tabor > > > > > -- > Pozdrawiam, > Piotr Tabor > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > > > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel Email Disclaimer: http://www.redprairie.com/emaildisclaimer/ |
|
From: John W. L. <Joh...@sa...> - 2010-09-28 21:39:59
|
I don't know what most people do, but if it was me, I would create regular wars/ears; copy them to the deploy directory; instrument them in place (by not using the todir attribute of cobertura-instrument). Since you are instrumenting a copy of the files, it should not impact your packaging. If you want client side coverage counts, then I would copy the jars and instrument them in place too. John From: Mike Miller [mailto:mi...@ho...] Sent: Tuesday, September 28, 2010 5:35 PM To: John W. Lewis; cob...@li... Subject: RE: [Cobertura-devel] Couple newbie questions Thanks for the quick response. So what do most people do for #2 below? Separate compiles and jar/war/ear creation or can you do something like instrumenting the jars/wars/ear that you deploy to the app server and then just use the original copy of the jars, etc from their build destination folder when you package the project/product? Our full build with test cases and installer creation currently takes about 1 1/2 hours so my preference to limit keep the time down but still get the benefit of having/providing code coverage reports. ________________________________ From: Joh...@sa... To: mi...@ho...; cob...@li... Subject: RE: [Cobertura-devel] Couple newbie questions Date: Tue, 28 Sep 2010 21:15:34 +0000 1) Yes 2) Yes. 3) Yes. From: Mike Miller [mailto:mi...@ho...] Sent: Tuesday, September 28, 2010 5:11 PM To: cob...@li... Subject: [Cobertura-devel] Couple newbie questions I used Cobertura shortly several years ago on a web application and now I want to provide code coverage reports for my current project. This is a large project using either JBoss or Weblogic with a lot of EJBs. I wanted to clarify a couple things before I got down making all of the build updates: 1) the general process/steps are compile,instrument, deploy and then report? 2) If the steps above are correct, doesn't that leave me with an instrumented version of my code-base once the build is completed? Trying to figure out if I need to create a full set of non-instrumented jars, wars, and ear and also a full set of instrumented jars, wars, and ear because the deployment artifacts from our nightly build are also used to create our InstallAnywhere build package. I don't believe I want to run into the case where my build uses the instrumented files as part of the installer package being built! 3) Our current JUnit tests are a combination of true JUnit testcases along with 'integration JUnit testcases' which exercise the EJB services from a client perspective. I assume this means that I will probably get 'sets' of .SER files, one from the client side and one from the server (once I stop JBoss or WLS). Do I then run the merge to create a unified .SER file and then generate the report from that unified SER? |
|
From: Mike M. <mi...@ho...> - 2010-09-28 21:35:15
|
Thanks for the quick response. So what do most people do for #2 below? Separate compiles and jar/war/ear creation or can you do something like instrumenting the jars/wars/ear that you deploy to the app server and then just use the original copy of the jars, etc from their build destination folder when you package the project/product? Our full build with test cases and installer creation currently takes about 1 1/2 hours so my preference to limit keep the time down but still get the benefit of having/providing code coverage reports. From: Joh...@sa... To: mi...@ho...; cob...@li... Subject: RE: [Cobertura-devel] Couple newbie questions Date: Tue, 28 Sep 2010 21:15:34 +0000 1) Yes 2) Yes. 3) Yes. From: Mike Miller [mailto:mi...@ho...] Sent: Tuesday, September 28, 2010 5:11 PM To: cob...@li... Subject: [Cobertura-devel] Couple newbie questions I used Cobertura shortly several years ago on a web application and now I want to provide code coverage reports for my current project. This is a large project using either JBoss or Weblogic with a lot of EJBs. I wanted to clarify a couple things before I got down making all of the build updates: 1) the general process/steps are compile,instrument, deploy and then report? 2) If the steps above are correct, doesn't that leave me with an instrumented version of my code-base once the build is completed? Trying to figure out if I need to create a full set of non-instrumented jars, wars, and ear and also a full set of instrumented jars, wars, and ear because the deployment artifacts from our nightly build are also used to create our InstallAnywhere build package. I don't believe I want to run into the case where my build uses the instrumented files as part of the installer package being built! 3) Our current JUnit tests are a combination of true JUnit testcases along with 'integration JUnit testcases' which exercise the EJB services from a client perspective. I assume this means that I will probably get 'sets' of .SER files, one from the client side and one from the server (once I stop JBoss or WLS). Do I then run the merge to create a unified .SER file and then generate the report from that unified SER? |
|
From: John W. L. <Joh...@sa...> - 2010-09-28 21:15:44
|
1) Yes 2) Yes. 3) Yes. From: Mike Miller [mailto:mi...@ho...] Sent: Tuesday, September 28, 2010 5:11 PM To: cob...@li... Subject: [Cobertura-devel] Couple newbie questions I used Cobertura shortly several years ago on a web application and now I want to provide code coverage reports for my current project. This is a large project using either JBoss or Weblogic with a lot of EJBs. I wanted to clarify a couple things before I got down making all of the build updates: 1) the general process/steps are compile,instrument, deploy and then report? 2) If the steps above are correct, doesn't that leave me with an instrumented version of my code-base once the build is completed? Trying to figure out if I need to create a full set of non-instrumented jars, wars, and ear and also a full set of instrumented jars, wars, and ear because the deployment artifacts from our nightly build are also used to create our InstallAnywhere build package. I don't believe I want to run into the case where my build uses the instrumented files as part of the installer package being built! 3) Our current JUnit tests are a combination of true JUnit testcases along with 'integration JUnit testcases' which exercise the EJB services from a client perspective. I assume this means that I will probably get 'sets' of .SER files, one from the client side and one from the server (once I stop JBoss or WLS). Do I then run the merge to create a unified .SER file and then generate the report from that unified SER? |
|
From: Mike M. <mi...@ho...> - 2010-09-28 21:11:08
|
I used Cobertura shortly several years ago on a web application and now I want to provide code coverage reports for my current project. This is a large project using either JBoss or Weblogic with a lot of EJBs. I wanted to clarify a couple things before I got down making all of the build updates: 1) the general process/steps are compile,instrument, deploy and then report? 2) If the steps above are correct, doesn't that leave me with an instrumented version of my code-base once the build is completed? Trying to figure out if I need to create a full set of non-instrumented jars, wars, and ear and also a full set of instrumented jars, wars, and ear because the deployment artifacts from our nightly build are also used to create our InstallAnywhere build package. I don't believe I want to run into the case where my build uses the instrumented files as part of the installer package being built! 3) Our current JUnit tests are a combination of true JUnit testcases along with 'integration JUnit testcases' which exercise the EJB services from a client perspective. I assume this means that I will probably get 'sets' of .SER files, one from the client side and one from the server (once I stop JBoss or WLS). Do I then run the merge to create a unified .SER file and then generate the report from that unified SER? |
|
From: Piotr T. <pio...@gm...> - 2010-09-26 21:46:29
|
I've worked on version in the brunch. The code is AFAIK test-before-release ready. I've migrated support for --ignoreTrivial and --ignoreAnnotations and added a new switch --threadsafeRigorous. In the mode cobertura is less faster then without the switch, but the counts of hits per line are precise in multithreaded situations. The switch should not affect the coverage results (% of hit lines and branches). My spare time is going to be over, so I don't plan any other changes then bugfixes to the reported problems with the new solution. Piotr Tabor On Mon, Sep 13, 2010 at 8:14 PM, John W. Lewis <Joh...@sa...> wrote: > > I’ll take a look – hopefully soon. > > > > *From:* Piotr Tabor [mailto:pio...@gm...] > *Sent:* Sunday, September 12, 2010 3:59 AM > *To:* cob...@li... > *Subject:* [Cobertura-devel] Major 'instrumentation code' refactoring > > > > Hello Cobertura masters, > > Long time ago (March) I promised to provide a really faster version of > Cobertura, but I started to be really busy then. Finally I found some time > and prepared it. > It is stored here: > https://cobertura.svn.sourceforge.net/svnroot/cobertura/branches/ptab_v2_0 > (should be probably 1.10) and the net.sourceforge.cobertura.instrument > package > is totally rewritten. > > The current status is: > > Additional benefits: > * Speed, speed, speed > * It is extremly close to supress requirement that *.sar file created > during instrumentation is needed during runtime. In fact the file is now > created > only for backward compability. > * SwitchFunctionalTest works now. Some simillar fixes to coverage in > other areas. > * I think that the new code is cleaner. > > Drawbacks: > * To count the hits I'm using in this implementation just: int[] > hits; > and to register hit I use: hits[...]++; > It is extremly fast, but not exactly thread safe. There will be no > 'exception' thrown or other problems, but we can > miss some hits (tests shows that it is <5% of hits). But it is > guaranteed that if there is at least one hit for a single touch-point, it > will be > registered. So it does not affect coverage, and seams to be > acceptable for 99.9% usage scenarios. > If required an exact-thread-safe mode can be implemented (see > AtomicArrayCodeProvider) > (but usege of AtomicIntegerArray causes significant (5-10 times) > performance decrease - but still is faster then cobertura 1.9.4+). > > TODO: > * ignore and ignore trival functionality has not been merged yet > * exact-thread-safe mode swotch > * The code need more tests > > I would appreciate if you (John ?) could have a look at the code and scribe > opinion about it. > > Regards, > Piotr Tabor > -- Pozdrawiam, Piotr Tabor |
|
From: Piotr T. <pi...@ta...> - 2010-09-21 19:18:29
|
Responses are near the questions: 2010/9/21 gopala krishna <gkn...@gm...> > Actually I have same package name and class name for some files in two > three modules. What will happen to coverage report of these files? will it > be over written? > If the classes are generated from exactly the same source-code the coverage should be right and hits will be added together. > > Also I have cobertura.ser files got generated on different servers from > different machines with different jdk versions like jdk1.6.03, 1.6.14 etc. > WHen we merge these files, do we get correct report? > I think so. But you have to use the same version of cobertura in all this environments. I'm not sure if it will work between jdk 1.5.x and 1.6.x. > > 2010/9/21 Jensen Bryan Ching <jen...@gm...> > >> >> From my understanding, the usual purpose of the merge ANT task is to >> aggregate data from different sub-modules of a project build into a single >> *.ser file. >> >> I would like to ask if the merge task can also be used to aggregate *.ser >> files from multiple builds of the same project, i.e. consolidating *.ser >> files which gathered coverage data for the same code set but compiled on >> multiple builds. Would the data be overwritten/would there be errors if >> source code was changed between multiple builds? >> > I don't thing so. The hits are addressed by line number. If anything in the source-code changes, the results will be corrupted. Piotr Tabor -- Pozdrawiam, Piotr Tabor |
|
From: Piotr T. <pi...@ta...> - 2010-09-21 19:16:49
|
2010/9/21 gopala krishna <gkn...@gm...> > Hi, > > I am using reflection in my java code. But I am getting zero percent > coverage for many classes which I am sure they should get coverage. Is there > any problem with cobertura in measuring code for classes that use > reflection? > > It should work. Piotr Tabor |
|
From: Piotr T. <pi...@ta...> - 2010-09-21 19:15:48
|
You can measure with cobertura GWT server code. The client-code that is transformed to Java Script and executed in browser will be not covered Of course if you test your client-code in java (using JUnit) and it is executed as java-code you can measure the coverage. Piotr Tabor 2010/9/20 John W. Lewis <Joh...@sa...> > > > If they are compiled as Java classes, then yes. > > > > *From:* gopala krishna [mailto:gkn...@gm...] > *Sent:* Monday, September 20, 2010 3:36 AM > *To:* cob...@li... > *Subject:* [Cobertura-devel] code coverage for gwt classes > > > > Hi, > > > > can we get code coverage for gwt classes that are there in app server? > > > > Regrads > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > -- Pozdrawiam, Piotr Tabor |
|
From: Jake C. <jak...@ga...> - 2010-09-21 15:19:05
|
Download the jars, instrument them and run them locally. If you've run it once already, there are probably copies already in your web start cache area. -Jake 2010/9/21 gopala krishna <gkn...@gm...> > Hi, > > How do I get coverage for a swing client that is loaded from app server > link using jnlp? > > Regards > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > |
|
From: gopala k. <gkn...@gm...> - 2010-09-21 13:14:58
|
Hi, How do I get coverage for a swing client that is loaded from app server link using jnlp? Regards |
|
From: John W. L. <Joh...@sa...> - 2010-09-21 11:13:06
|
You can use 1.6. I think you will be ok with different versions of 1.6. From: gopala krishna [mailto:gkn...@gm...] Sent: Tuesday, September 21, 2010 2:28 AM To: cob...@li... Subject: [Cobertura-devel] cobertura1.9.4.jar with jdk1.6 Hi, can I use this coberura jar with jdk1.6? Also I have .ser files generated with different versions of jdk1.6 Will it be a problem while mergin them? Regards |
|
From: gopala k. <gkn...@gm...> - 2010-09-21 06:28:33
|
Hi, can I use this coberura jar with jdk1.6? Also I have .ser files generated with different versions of jdk1.6 Will it be a problem while mergin them? Regards |
|
From: gopala k. <gkn...@gm...> - 2010-09-21 06:25:42
|
Hi, I am using reflection in my java code. But I am getting zero percent coverage for many classes which I am sure they should get coverage. Is there any problem with cobertura in measuring code for classes that use reflection? Regards |
|
From: gopala k. <gkn...@gm...> - 2010-09-21 05:40:16
|
Hi, Actually I have same package name and class name for some files in two three modules. What will happen to coverage report of these files? will it be over written? Also I have cobertura.ser files got generated on different servers from different machines with different jdk versions like jdk1.6.03, 1.6.14 etc. WHen we merge these files, do we get correct report? Thanks in advance |
|
From: gopala k. <gkn...@gm...> - 2010-09-21 05:39:34
|
I am also interested in this question. Actually I have same package name and class name for some files in two three modules. What will happen to coverage report of these files? will it be over written? Also I have cobertura.ser files got generated on different servers from different machines with different jdk versions like jdk1.6.03, 1.6.14 etc. WHen we merge these files, do we get correct report? Thanks in advance 2010/9/21 Jensen Bryan Ching <jen...@gm...> > Good day, > > From my understanding, the usual purpose of the merge ANT task is to > aggregate data from different sub-modules of a project build into a single > *.ser file. > > I would like to ask if the merge task can also be used to aggregate *.ser > files from multiple builds of the same project, i.e. consolidating *.ser > files which gathered coverage data for the same code set but compiled on > multiple builds. Would the data be overwritten/would there be errors if > source code was changed between multiple builds? > > Regards, > Jensen > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > |
|
From: Jensen B. C. <jen...@gm...> - 2010-09-21 01:31:24
|
Good day, >From my understanding, the usual purpose of the merge ANT task is to aggregate data from different sub-modules of a project build into a single *.ser file. I would like to ask if the merge task can also be used to aggregate *.ser files from multiple builds of the same project, i.e. consolidating *.ser files which gathered coverage data for the same code set but compiled on multiple builds. Would the data be overwritten/would there be errors if source code was changed between multiple builds? Regards, Jensen |
|
From: John W. L. <Joh...@sa...> - 2010-09-20 09:34:01
|
If they are compiled as Java classes, then yes. From: gopala krishna [mailto:gkn...@gm...] Sent: Monday, September 20, 2010 3:36 AM To: cob...@li... Subject: [Cobertura-devel] code coverage for gwt classes Hi, can we get code coverage for gwt classes that are there in app server? Regrads |
89 messages has been excluded from this view by a project administrator.
