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: Steve C. <sch...@gm...> - 2012-11-30 19:52:00
|
You should never have to deploy an instrumented war file to a deployed environment. If i'm correct you are using maven to try and instrument. The cobertura ant task has a "todir" variable which creates a new file with instrumented code that way you have 2 different copies (one instrumented and one not instrumented). You will need to investigate if maven can do this at all. Thanks, Steve. On Fri, Nov 30, 2012 at 1:40 PM, Gordon Harris <gor...@ya...> wrote: > Hi, > > I am using cobertura for the first time. I'm trying to understand the > right way to use it with Jenkins CI. > > We are writing a webapp. We have unit tests. Jenkins is setup to perform > maven builds triggered by svn commits. The last step of a successful build > is to deploy the generated war to a Tomcat instance for QA/demo purposes. > > I have Jenkins and the pom setup to run tests with cobertura. Jenkins > shows lovely cobertura graphs :) > > My concern is that we should NOT be deploying the instrumented war to > Tomcat. I do not need to track code coverage in the deployed environment. > Tomcat should be running the app as may be released to production (ie. > non-instrumented). But AFAIK there's only the one war being generated by > the build. > > What's the right thing to do here? Am I mistaken about what the build > generates? Is the solution to have separate projects running in Jenkins, > one for cobertura and one for deploying to Tomcat? What do other people do? > > > Gord > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > TUNE You got it built. Now make it sing. Tune shows you how. > http://goparallel.sourceforge.net > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > |
From: Gordon H. <gor...@ya...> - 2012-11-30 19:40:45
|
Hi, I am using cobertura for the first time. I'm trying to understand the right way to use it with Jenkins CI. We are writing a webapp. We have unit tests. Jenkins is setup to perform maven builds triggered by svn commits. The last step of a successful build is to deploy the generated war to a Tomcat instance for QA/demo purposes. I have Jenkins and the pom setup to run tests with cobertura. Jenkins shows lovely cobertura graphs :) My concern is that we should NOT be deploying the instrumented war to Tomcat. I do not need to track code coverage in the deployed environment. Tomcat should be running the app as may be released to production (ie. non-instrumented). But AFAIK there's only the one war being generated by the build. What's the right thing to do here? Am I mistaken about what the build generates? Is the solution to have separate projects running in Jenkins, one for cobertura and one for deploying to Tomcat? What do other people do? Gord |
From: John W. L. <Joh...@sa...> - 2012-11-21 16:24:24
|
Hi Daniel, Thanks for your interest in Cobertura. There are a couple of Java 7 patches that have been submitted, but they both have issues that I have put in the comments. Here they are: https://sourceforge.net/tracker/index.php?func=detail&aid=3431812&group_id=130558&atid=720017 https://sourceforge.net/tracker/index.php?func=detail&aid=3513556&group_id=130558&atid=720017 I would really like to get a release of Cobertura that is compatible with Java 7 as soon as possible. John From: Daniel Wainwright [mailto:wai...@gm...] Sent: Friday, October 12, 2012 5:32 AM To: cob...@li... Subject: [Cobertura-devel] Cobertura on Java 7 Hi, I have started using Cobertura recently, and find it to be an excellent and invaluable tool. I was disappointed to find out that it doesn't currently support Java 7 features, and that there does not seem to be any development in this direction (please correct me if I am wrong). If this indeed is the case, I would like to look into adding this functionality to Cobertura myself. If anyone has started development in this direction, or has ideas/pointers about the best way to achieve this, I would be grateful for your suggestions or advice. I have worked with instrumentation in other compiler/optimizer frameworks before (LLVM and Soot) and know the concepts of ASM, although I have never used it myself. I understand the first requirement to support Java 7 would be to move to ASM 4.0. I hope this is the best place to ask these questions (I am talking about development, not just requesting it), please forgive me if I am wrong. Daniel -- Regards, Daniel Wainwright |
From: KARR, D. <dk...@at...> - 2012-11-15 17:03:54
|
For the benefit of the list, I managed to figure this out. It was helpful to remember the "log4j.debug" property, which tells you where it found a log4j.properties or log4j.xml file. I found the latter in an unexpected jar file, which had stupid settings in it. From: KARR, DAVID Sent: Tuesday, November 13, 2012 1:26 PM To: Steve Christou Cc: cob...@li... Subject: Re: [Cobertura-devel] Is loading and saving before each unit test expensive? Thanks, that appears to help. Once I can get Cobertura to not emit debug output, generating code coverage will be almost painless. From: Steve Christou [mailto:sch...@gm...] Sent: Tuesday, November 13, 2012 1:09 PM To: KARR, DAVID Cc: cob...@li...<mailto:cob...@li...> Subject: Re: [Cobertura-devel] Is loading and saving before each unit test expensive? That's because you have forkedmode set to default in your junit arguments. The method you are currently doing is a very expensive method for junit testing. Here's how junit (default) with cobertura works. Say we have 10 unit tests (test1-test10). When the jvm first starts it immediately creates a map for cobertura and begins to take note of all the line numbers and other items for keeping track of instrumented code(magic). When the jvm shuts down cobertura has a "release" task where it writes code to the .ser file. This is where you see the Loaded information on 816 classes. It will then save the infrormation to the file and be complete. Now here's where the inefficient part comes in. The default junit ant target has something called fork which essentially means "Create a new JVM for every single unit test". That means for test1 though test10 you will see about 10 jvms started up and shut down. so you will see all the loaded and saved information constantly. There are good and bad reasons for this: Good: No leaking data - Static (non-final) variables are not an issue. No issues with legacy code. Legacy code can have no failures. Bad: Incredibly slow (I've seen unit tests take 2+ hours vs 30 minutes with this option). Proof of bad junit (junits should never contain leaking data, or need to clean up properly in tearDown methods). The only way you can fix this issue is to set forkmode="once" as part of your ant target. Again this COULD cause junits to fail, however it will increase the speed of the junits by a lot. See the documentation on forkmode: http://ant.apache.org/manual/Tasks/junit.html On Tue, Nov 13, 2012 at 2:47 PM, KARR, DAVID <dk...@at...<mailto:dk...@at...>> wrote: As Cobertura is excessively verbose right now, I notice that before every unit test class is run, I see the following: ---------------- Cobertura: Loaded information on 816 classes. Cobertura: Saved information on 816 classes. ---------------- Obviously, the number of classes loaded and saved will vary, but it really is doing this before very single unit test class, even when all of them were spawned from the same "junit" task. I first wonder if it's expensive to do this, and second I would wonder whether it's reasonable or possible to do this load and save at a higher scope, like only once for each "junit" task invocation. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Cobertura-devel mailing list Cob...@li...<mailto:Cob...@li...> https://lists.sourceforge.net/lists/listinfo/cobertura-devel |
From: John W. L. <Joh...@sa...> - 2012-11-15 15:22:52
|
The logging level during instrumentation is determined by the log4j settings. My bet is that you have a log4j.properties file in the classpath during instrumentation. It is probably on the classpath before the cobertura.jar since the cobertura.jar also has a log4j.properties file. It is also possible that someone may have modified the log4j.properties file that is in your cobertura.jar. -----Original Message----- From: KARR, DAVID [mailto:dk...@at...] Sent: Tuesday, November 13, 2012 10:06 AM To: Matthieu Moy Cc: cob...@li... Subject: Re: [Cobertura-devel] How to turn off Cobertura debug output > -----Original Message----- > From: Matthieu Moy [mailto:Mat...@gr...] > Sent: Tuesday, November 13, 2012 12:33 AM > To: KARR, DAVID > Cc: cob...@li... > Subject: Re: [Cobertura-devel] How to turn off Cobertura debug output > > "KARR, DAVID" <dk...@at...> writes: > > > I recently set up some Ant targets to run Cobertura with our unit > > tests. I got it to work, but I noticed today that Cobertura suddenly > > decided to emit its debug output, > > You mean those > > Flushing results... > Flushing results done > Cobertura: Loaded information on 167 classes. > Cobertura: Saved information on 167 classes. > > ? Actually, those are annoying, and I'd like to reduce them, but yesterday the volume increased a hundredfold, with lines like this for every single file being processed: 2012-11-12 15:52:30,753 DEBUG [net.sourceforge.cobertura.instrument.Main] [addInstrumentationToSingleClass] [Thread:main] - [Instrumenting class ... 2012-11-12 15:54:43,351 DEBUG [net.sourceforge.cobertura.util.FileFinder] [getFileForSource] [Thread:main] - [Searching for file, name=[... 2012-11-12 15:55:05,656 DEBUG [net.sourceforge.cobertura.reporting.xml.XMLReport] [dumpClass] [Thread:main] - [Dumping class ... 2012-11-12 15:55:44,245 DEBUG [net.sourceforge.cobertura.util.FileFinder] [getFileForSource] [Thread:main] - [Searching for file, name=[... I got a direct reply on this from someone on the project who said this is a known problem, and they're working on a fix. > > which produces a great deal of output. I didn't intentionally turn > > this on, and I don't see what might be turning this on. I'm just > using > > the "cobertura-instrument" task without any special flags. What > > might be doing this? > > The cobertura-instrumented classes call the cobertura runtime that > produces these outputs. I also have problem with them, and proposed a > patch to allow the user to disable it: > > > http://sourceforge.net/tracker/?func=detail&aid=3577330&group_id=13055 > 8 > &atid=720017 > > Unfortunately, it seems the patch didn't receive any attention. > > Do I need to do anything to have the patch applied? What is the github > migration status? Shall I submit a merge request anywhere? > > Thanks, > > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Cobertura-devel mailing list Cob...@li... https://lists.sourceforge.net/lists/listinfo/cobertura-devel |
From: KARR, D. <dk...@at...> - 2012-11-13 21:26:35
|
Thanks, that appears to help. Once I can get Cobertura to not emit debug output, generating code coverage will be almost painless. From: Steve Christou [mailto:sch...@gm...] Sent: Tuesday, November 13, 2012 1:09 PM To: KARR, DAVID Cc: cob...@li... Subject: Re: [Cobertura-devel] Is loading and saving before each unit test expensive? That's because you have forkedmode set to default in your junit arguments. The method you are currently doing is a very expensive method for junit testing. Here's how junit (default) with cobertura works. Say we have 10 unit tests (test1-test10). When the jvm first starts it immediately creates a map for cobertura and begins to take note of all the line numbers and other items for keeping track of instrumented code(magic). When the jvm shuts down cobertura has a "release" task where it writes code to the .ser file. This is where you see the Loaded information on 816 classes. It will then save the infrormation to the file and be complete. Now here's where the inefficient part comes in. The default junit ant target has something called fork which essentially means "Create a new JVM for every single unit test". That means for test1 though test10 you will see about 10 jvms started up and shut down. so you will see all the loaded and saved information constantly. There are good and bad reasons for this: Good: No leaking data - Static (non-final) variables are not an issue. No issues with legacy code. Legacy code can have no failures. Bad: Incredibly slow (I've seen unit tests take 2+ hours vs 30 minutes with this option). Proof of bad junit (junits should never contain leaking data, or need to clean up properly in tearDown methods). The only way you can fix this issue is to set forkmode="once" as part of your ant target. Again this COULD cause junits to fail, however it will increase the speed of the junits by a lot. See the documentation on forkmode: http://ant.apache.org/manual/Tasks/junit.html On Tue, Nov 13, 2012 at 2:47 PM, KARR, DAVID <dk...@at...<mailto:dk...@at...>> wrote: As Cobertura is excessively verbose right now, I notice that before every unit test class is run, I see the following: ---------------- Cobertura: Loaded information on 816 classes. Cobertura: Saved information on 816 classes. ---------------- Obviously, the number of classes loaded and saved will vary, but it really is doing this before very single unit test class, even when all of them were spawned from the same "junit" task. I first wonder if it's expensive to do this, and second I would wonder whether it's reasonable or possible to do this load and save at a higher scope, like only once for each "junit" task invocation. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Cobertura-devel mailing list Cob...@li...<mailto:Cob...@li...> https://lists.sourceforge.net/lists/listinfo/cobertura-devel |
From: Steve C. <sch...@gm...> - 2012-11-13 21:08:40
|
That's because you have forkedmode set to default in your junit arguments. The method you are currently doing is a very expensive method for junit testing. Here's how junit (default) with cobertura works. Say we have 10 unit tests (test1-test10). When the jvm first starts it immediately creates a map for cobertura and begins to take note of all the line numbers and other items for keeping track of instrumented code(magic). When the jvm shuts down cobertura has a "release" task where it writes code to the .ser file. This is where you see the Loaded information on 816 classes. It will then save the infrormation to the file and be complete. Now here's where the inefficient part comes in. The default junit ant target has something called fork which essentially means "Create a new JVM for every single unit test". That means for test1 though test10 you will see about 10 jvms started up and shut down. so you will see all the loaded and saved information constantly. There are good and bad reasons for this: Good: No leaking data - Static (non-final) variables are not an issue. No issues with legacy code. Legacy code can have no failures. Bad: Incredibly slow (I've seen unit tests take 2+ hours vs 30 minutes with this option). Proof of bad junit (junits should never contain leaking data, or need to clean up properly in tearDown methods). The only way you can fix this issue is to set forkmode="once" as part of your ant target. Again this COULD cause junits to fail, however it will increase the speed of the junits by a lot. See the documentation on forkmode: http://ant.apache.org/manual/Tasks/junit.html On Tue, Nov 13, 2012 at 2:47 PM, KARR, DAVID <dk...@at...> wrote: > As Cobertura is excessively verbose right now, I notice that before every > unit test class is run, I see the following: > ---------------- > Cobertura: Loaded information on 816 classes. > Cobertura: Saved information on 816 classes. > ---------------- > > Obviously, the number of classes loaded and saved will vary, but it really > is doing this before very single unit test class, even when all of them > were spawned from the same "junit" task. I first wonder if it's expensive > to do this, and second I would wonder whether it's reasonable or possible > to do this load and save at a higher scope, like only once for each "junit" > task invocation. > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > |
From: KARR, D. <dk...@at...> - 2012-11-13 20:47:56
|
As Cobertura is excessively verbose right now, I notice that before every unit test class is run, I see the following: ---------------- Cobertura: Loaded information on 816 classes. Cobertura: Saved information on 816 classes. ---------------- Obviously, the number of classes loaded and saved will vary, but it really is doing this before very single unit test class, even when all of them were spawned from the same "junit" task. I first wonder if it's expensive to do this, and second I would wonder whether it's reasonable or possible to do this load and save at a higher scope, like only once for each "junit" task invocation. |
From: KARR, D. <dk...@at...> - 2012-11-13 15:07:06
|
> -----Original Message----- > From: Matthieu Moy [mailto:Mat...@gr...] > Sent: Tuesday, November 13, 2012 12:33 AM > To: KARR, DAVID > Cc: cob...@li... > Subject: Re: [Cobertura-devel] How to turn off Cobertura debug output > > "KARR, DAVID" <dk...@at...> writes: > > > I recently set up some Ant targets to run Cobertura with our unit > > tests. I got it to work, but I noticed today that Cobertura suddenly > > decided to emit its debug output, > > You mean those > > Flushing results... > Flushing results done > Cobertura: Loaded information on 167 classes. > Cobertura: Saved information on 167 classes. > > ? Actually, those are annoying, and I'd like to reduce them, but yesterday the volume increased a hundredfold, with lines like this for every single file being processed: 2012-11-12 15:52:30,753 DEBUG [net.sourceforge.cobertura.instrument.Main] [addInstrumentationToSingleClass] [Thread:main] - [Instrumenting class ... 2012-11-12 15:54:43,351 DEBUG [net.sourceforge.cobertura.util.FileFinder] [getFileForSource] [Thread:main] - [Searching for file, name=[... 2012-11-12 15:55:05,656 DEBUG [net.sourceforge.cobertura.reporting.xml.XMLReport] [dumpClass] [Thread:main] - [Dumping class ... 2012-11-12 15:55:44,245 DEBUG [net.sourceforge.cobertura.util.FileFinder] [getFileForSource] [Thread:main] - [Searching for file, name=[... I got a direct reply on this from someone on the project who said this is a known problem, and they're working on a fix. > > which produces a great deal of output. I didn't intentionally turn > > this on, and I don't see what might be turning this on. I'm just > using > > the "cobertura-instrument" task without any special flags. What might > > be doing this? > > The cobertura-instrumented classes call the cobertura runtime that > produces these outputs. I also have problem with them, and proposed a > patch to allow the user to disable it: > > > http://sourceforge.net/tracker/?func=detail&aid=3577330&group_id=130558 > &atid=720017 > > Unfortunately, it seems the patch didn't receive any attention. > > Do I need to do anything to have the patch applied? What is the github > migration status? Shall I submit a merge request anywhere? > > Thanks, > > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/ |
From: Matthieu M. <Mat...@gr...> - 2012-11-13 08:32:58
|
"KARR, DAVID" <dk...@at...> writes: > I recently set up some Ant targets to run Cobertura with our unit > tests. I got it to work, but I noticed today that Cobertura suddenly > decided to emit its debug output, You mean those Flushing results... Flushing results done Cobertura: Loaded information on 167 classes. Cobertura: Saved information on 167 classes. ? > which produces a great deal of output. I didn't intentionally turn > this on, and I don't see what might be turning this on. I'm just using > the "cobertura-instrument" task without any special flags. What might > be doing this? The cobertura-instrumented classes call the cobertura runtime that produces these outputs. I also have problem with them, and proposed a patch to allow the user to disable it: http://sourceforge.net/tracker/?func=detail&aid=3577330&group_id=130558&atid=720017 Unfortunately, it seems the patch didn't receive any attention. Do I need to do anything to have the patch applied? What is the github migration status? Shall I submit a merge request anywhere? Thanks, -- Matthieu Moy http://www-verimag.imag.fr/~moy/ |
From: KARR, D. <dk...@at...> - 2012-11-13 00:10:21
|
I recently set up some Ant targets to run Cobertura with our unit tests. I got it to work, but I noticed today that Cobertura suddenly decided to emit its debug output, which produces a great deal of output. I didn't intentionally turn this on, and I don't see what might be turning this on. I'm just using the "cobertura-instrument" task without any special flags. What might be doing this? |
From: KARR, D. <dk...@at...> - 2012-11-07 18:15:10
|
> -----Original Message----- > From: KARR, DAVID > Sent: Wednesday, November 07, 2012 9:18 AM > To: cob...@li... > Subject: [Cobertura-devel] Error running cobertura-report from Ant > > I'm integrating running of unit tests along with Cobertura into a big > Ant script (I can't wait to convert this mess to Maven). The unit > tests are working, and Cobertura appears to be instrumenting, but when > I try to generate the Cobertura report, I get this: > > coverage-report: > Created dir: C:\Documents and > Settings\dk068x\workspace6\externalservices- > trunk\gen\reports\artifacts\coverage > Trying to override old definition of task cobertura-instrument > Trying to override old definition of task cobertura-merge > Trying to override old definition of task cobertura-check > Trying to override old definition of task cobertura-report > java.io.IOException: Cannot run program > "C:\eclipse\Java\jdk1.6.0_30\jre\bin\java.exe": CreateProcess > error=206, The filename or extension is too long > at org.apache.tools.ant.taskdefs.Java.fork(Java.java:791) > > This is my Ant task definition: > > <target name="coverage-report"> > <mkdir dir="${artifacts.coverage.dir}" /> > <mkdir dir="${reports.coverage.dir}" /> > <cobertura-report datafile="${basedir}/cobertura.ser" > srcdir="${main.src.dir}" destdir="${artifacts.coverage.dir}" > format="xml" /> > <cobertura-report datafile="${basedir}/cobertura.ser" > srcdir="${main.src.dir}" destdir="${reports.coverage.dir}" > format="html" /> > </target> > > I find it curious that the documentation on > http://cobertura.sourceforge.net/anttaskreference.html doesn't quite > match the property completion choices that Eclipse provides. I see > several properties suggested by Eclipse that aren't mentioned in the > documentation. > > I have another project using Maven that is having no trouble generating > Cobertura reports. After some more research, I'm finding that this is likely a problem with my classpath simply being too long. That will likely be very annoying to fix. However, and even more annoyingly, when I just tried to run this command line again, it simply worked. No error. I tried it again, and it still worked. I then cleaned everything and reran it, and it still worked. Very disturbing. |
From: KARR, D. <dk...@at...> - 2012-11-07 17:18:36
|
I'm integrating running of unit tests along with Cobertura into a big Ant script (I can't wait to convert this mess to Maven). The unit tests are working, and Cobertura appears to be instrumenting, but when I try to generate the Cobertura report, I get this: coverage-report: Created dir: C:\Documents and Settings\dk068x\workspace6\externalservices-trunk\gen\reports\artifacts\coverage Trying to override old definition of task cobertura-instrument Trying to override old definition of task cobertura-merge Trying to override old definition of task cobertura-check Trying to override old definition of task cobertura-report java.io.IOException: Cannot run program "C:\eclipse\Java\jdk1.6.0_30\jre\bin\java.exe": CreateProcess error=206, The filename or extension is too long at org.apache.tools.ant.taskdefs.Java.fork(Java.java:791) This is my Ant task definition: <target name="coverage-report"> <mkdir dir="${artifacts.coverage.dir}" /> <mkdir dir="${reports.coverage.dir}" /> <cobertura-report datafile="${basedir}/cobertura.ser" srcdir="${main.src.dir}" destdir="${artifacts.coverage.dir}" format="xml" /> <cobertura-report datafile="${basedir}/cobertura.ser" srcdir="${main.src.dir}" destdir="${reports.coverage.dir}" format="html" /> </target> I find it curious that the documentation on http://cobertura.sourceforge.net/anttaskreference.html doesn't quite match the property completion choices that Eclipse provides. I see several properties suggested by Eclipse that aren't mentioned in the documentation. I have another project using Maven that is having no trouble generating Cobertura reports. |
From: Steve C. <sch...@gm...> - 2012-11-06 05:58:10
|
Can you send the instrumented code along with the .ser file? Might be a bug. I also is this compiled with jdk 7? What exact version? Thanks, Steve. On Nov 5, 2012 5:48 PM, "KHURRAM FARAAZ" <khf...@gm...> wrote: > > Hi > > I use cobertura with ant to generate coverage report for our multi module maven project. > I am using cobertura 1.9.4.1 > > I run it this way to generate the html coverage report. > > mvn clean compile > ant instrument > mvn test > ant report > > The line coverage is generated for all classes in all packages. > > However, branch coverage is reported as ZERO for all classes in all packages. > > Interestingly, where ever there is a branch (if/while etc) that line is highlighted in that clas in the coverage report and the number of times that expression is executed is also shown within that class on the second column on the left. > > At a package level branch coverage is reported as zero ? > > And why is the if/while or other conditional branch statement highlighted as red and at the same time for that very highlighted conditional expression/branch expression why is it that on the second column on the left the coverage tool shows how many times that condition was executed. > > Is this a bug ? am I missing something ? > > Thanks > > > ---------- Forwarded message ---------- > From: KHURRAM FARAAZ <khf...@gm...> > Date: Fri, Oct 12, 2012 at 9:47 PM > Subject: Re: Branch Coverage reported as zero for all packages > To: cob...@li... > > > resending > > On Fri, Oct 12, 2012 at 9:45 PM, < cob...@li...> wrote: >> >> You are not allowed to post to this mailing list, and your message has >> been automatically rejected. If you think that your messages are >> being rejected in error, contact the mailing list owner at >> cob...@li.... >> >> >> >> ---------- Forwarded message ---------- >> From: KHURRAM FARAAZ <khf...@gm...> >> To: cob...@li... >> Cc: >> Date: Fri, 12 Oct 2012 21:45:50 -0700 >> Subject: Branch Coverage reported as zero for all packages >> Hi >> >> I use cobertura with ant to generate coverage report for our multi module maven project. >> I am using cobertura 1.9.4.1 >> >> I run it this way to generate the html coverage report. >> >> mvn clean compile >> ant instrument >> mvn test >> ant report >> >> The line coverage is generated for all classes in all packages. >> >> However, branch coverage is reported as ZERO for all classes in all packages. >> >> Interestingly, where ever there is a branch (if/while etc) that line is highlighted in that clas in the coverage report and the number of times that expression is executed is also shown within that class on the second column on the left. >> >> At a package level branch coverage is reported as zero ? >> >> And why is the if/while or other conditional branch statement highlighted as red and at the same time for that very highlighted conditional expression/branch expression why is it that on the second column on the left the coverage tool shows how many times that condition was executed. >> >> Is this a bug ? am I missing something ? >> >> Thanks >> > > > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > |
From: KHURRAM F. <khf...@gm...> - 2012-11-05 23:45:58
|
Hi I use cobertura with ant to generate coverage report for our multi module maven project. I am using cobertura 1.9.4.1 I run it this way to generate the html coverage report. mvn clean compile ant instrument mvn test ant report The line coverage is generated for all classes in all packages. However, branch coverage is reported as ZERO for all classes in all packages. Interestingly, where ever there is a branch (if/while etc) that line is highlighted in that clas in the coverage report and the number of times that expression is executed is also shown within that class on the second column on the left. At a package level branch coverage is reported as zero ? And why is the if/while or other conditional branch statement highlighted as red and at the same time for that very highlighted conditional expression/branch expression why is it that on the second column on the left the coverage tool shows how many times that condition was executed. Is this a bug ? am I missing something ? Thanks ---------- Forwarded message ---------- From: KHURRAM FARAAZ <khf...@gm...> Date: Fri, Oct 12, 2012 at 9:47 PM Subject: Re: Branch Coverage reported as zero for all packages To: cob...@li... resending On Fri, Oct 12, 2012 at 9:45 PM, < cob...@li...> wrote: > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > cob...@li.... > > > > ---------- Forwarded message ---------- > From: KHURRAM FARAAZ <khf...@gm...> > To: cob...@li... > Cc: > Date: Fri, 12 Oct 2012 21:45:50 -0700 > Subject: Branch Coverage reported as zero for all packages > Hi > > I use cobertura with ant to generate coverage report for our multi module > maven project. > I am using cobertura 1.9.4.1 > > I run it this way to generate the html coverage report. > > mvn clean compile > ant instrument > mvn test > ant report > > The line coverage is generated for all classes in all packages. > > However, branch coverage is reported as ZERO for all classes in all > packages. > > Interestingly, where ever there is a branch (if/while etc) that line is > highlighted in that clas in the coverage report and the number of times > that expression is executed is also shown within that class on the second > column on the left. > > At a package level branch coverage is reported as zero ? > > And why is the if/while or other conditional branch statement highlighted > as red and at the same time for that very highlighted conditional > expression/branch expression why is it that on the second column on the > left the coverage tool shows how many times that condition was executed. > > Is this a bug ? am I missing something ? > > Thanks > > |
From: José M. R. <jmr...@gm...> - 2012-10-30 00:02:23
|
Hello, This was done on top of trunk. Should we add a branch linking the ptab_v2_0 svn branch, where dev is being done? Jose. 2012/10/26 Steve Christou <sch...@gm...> > I was just about to migrate cobertura over to github this weekend, and I > was going to see about moving to maven in the future. What branch did you > fork? > > Sent from Windows Mail > > *From:* José Martin Rozanec > *Sent:* October 26, 2012 3:42 PM > *To:* cob...@li... > *Subject:* [Cobertura-devel] Contribution to Cobertura project > > Hello, > > I've been working on some ideas for Cobertura project, and I wanted to > contribute this code to it and get some feedback from the Cobertura team, > if may be interested on this. > This is still being developed / is in a work-in-progress state. > The code is available here: https://github.com/code54/cobertura-chocolate > > *Why the changes? / Objectives:* > - tests should run once. Due to original Cobertura design, users were > forced to run instrumentation and tests immediately, and later run tests > again to see if something was broken. > - expose more data. Ex.: expose coverage thresholds and coverage data on > reports, allow to build custom metrics. Serialize data in a readable format. > - decouple from Ant and provide a DSL to set parameters, run code > instrumentation and provide programatic access to results > - provide means to add new metrics > - provide means to support multiple JVM languages > - provide a report where all metrics, thresholds and sourcelines are > stored. This way we no longer need to recompile/instrument and test to > generate a report and no longer depend on source code: represents code's > snapshot. New reports in different formats can be created using it. > > *What is done:* > - migrated Cobertura to Git and Maven, > - removed static initialization > - move away from Ant tasks and provided a DSL that wrapps them. This > allows us to run compilation, instrumentation, tests and reports creation > separately (some tests were created for this: > see CodeInstrumentationIntegrationTest). Tests run once! > - provide xml serialization for ProjectData: serialized data is now human > readable. > - provide an interface so that users can create their own metrics. This > are loaded by reflection. > - separate ProjectData from reporting layer. A GenericReport is created > from ProjectData metrics. Will also include custom metrics results. > Introducing GenericReport we no longer > -- require compilation/instrumentation/test steps to export to different > report formats. GenericReport stores a snapshot. > -- depend on ProjectData > -- depend on project source files > Serializing GenericReport, we should be able to produce any reports. > All code information (Project, Package, Sourcefile, Class, Method, Line) > is treated as a graph. We provide filters and criterias to query it. > > Looking at the code, you'll notice that most changes do not affect the > existing Cobertura code, but there is much work being done on top of it. > > *Does the code contain bugs?* > Yes, it does. If you find some, please provide feedback :) If you think > this is an interesting idea, consider contributing some code. > > *Known limitations / issues:* > When using the DSL > - currently we need to resolve how do we deal with thresholds on > GenericReport > - currently there is a bug around including source lines into > GenericReport. If you > run CodeInstrumentationIntegrationTest::testExportXml() you'll get an xml > report, but no source lines will be exported. > - html report needs to be fixed > - we are not handling war/jar/ear instrumentation > - we are not supporting old xml formats from the DSL. > This limitations are TODOs, and will be handled in a future. > > *Next steps* > - add more tests > - finish the GenericReport implementation regarding thresholds and fix the > code lines bug > - support old xml formats > - fix html format > - develop report builders for other JVM languages > .... > > > What are your thoughts about this? > > Jose. > > > ------------------------------------------------------------------------------ > WINDOWS 8 is here. > Millions of people. Your app in 30 days. > Visit The Windows 8 Center at Sourceforge for all your go to resources. > http://windows8center.sourceforge.net/ > join-generation-app-and-make-money-coding-fast/ > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > |
From: Steve C. <sch...@gm...> - 2012-10-26 23:40:53
|
I was just about to migrate cobertura over to github this weekend, and I was going to see about moving to maven in the future. What branch did you fork? Sent from Windows Mail *From:* José Martin Rozanec *Sent:* October 26, 2012 3:42 PM *To:* cob...@li... *Subject:* [Cobertura-devel] Contribution to Cobertura project Hello, I've been working on some ideas for Cobertura project, and I wanted to contribute this code to it and get some feedback from the Cobertura team, if may be interested on this. This is still being developed / is in a work-in-progress state. The code is available here: https://github.com/code54/cobertura-chocolate *Why the changes? / Objectives:* - tests should run once. Due to original Cobertura design, users were forced to run instrumentation and tests immediately, and later run tests again to see if something was broken. - expose more data. Ex.: expose coverage thresholds and coverage data on reports, allow to build custom metrics. Serialize data in a readable format. - decouple from Ant and provide a DSL to set parameters, run code instrumentation and provide programatic access to results - provide means to add new metrics - provide means to support multiple JVM languages - provide a report where all metrics, thresholds and sourcelines are stored. This way we no longer need to recompile/instrument and test to generate a report and no longer depend on source code: represents code's snapshot. New reports in different formats can be created using it. *What is done:* - migrated Cobertura to Git and Maven, - removed static initialization - move away from Ant tasks and provided a DSL that wrapps them. This allows us to run compilation, instrumentation, tests and reports creation separately (some tests were created for this: see CodeInstrumentationIntegrationTest). Tests run once! - provide xml serialization for ProjectData: serialized data is now human readable. - provide an interface so that users can create their own metrics. This are loaded by reflection. - separate ProjectData from reporting layer. A GenericReport is created from ProjectData metrics. Will also include custom metrics results. Introducing GenericReport we no longer -- require compilation/instrumentation/test steps to export to different report formats. GenericReport stores a snapshot. -- depend on ProjectData -- depend on project source files Serializing GenericReport, we should be able to produce any reports. All code information (Project, Package, Sourcefile, Class, Method, Line) is treated as a graph. We provide filters and criterias to query it. Looking at the code, you'll notice that most changes do not affect the existing Cobertura code, but there is much work being done on top of it. *Does the code contain bugs?* Yes, it does. If you find some, please provide feedback :) If you think this is an interesting idea, consider contributing some code. *Known limitations / issues:* When using the DSL - currently we need to resolve how do we deal with thresholds on GenericReport - currently there is a bug around including source lines into GenericReport. If you run CodeInstrumentationIntegrationTest::testExportXml() you'll get an xml report, but no source lines will be exported. - html report needs to be fixed - we are not handling war/jar/ear instrumentation - we are not supporting old xml formats from the DSL. This limitations are TODOs, and will be handled in a future. *Next steps* - add more tests - finish the GenericReport implementation regarding thresholds and fix the code lines bug - support old xml formats - fix html format - develop report builders for other JVM languages .... What are your thoughts about this? Jose. ------------------------------------------------------------------------------ WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ _______________________________________________ Cobertura-devel mailing list Cob...@li... https://lists.sourceforge.net/lists/listinfo/cobertura-devel |
From: José M. R. <jmr...@gm...> - 2012-10-26 22:41:36
|
Hello, I've been working on some ideas for Cobertura project, and I wanted to contribute this code to it and get some feedback from the Cobertura team, if may be interested on this. This is still being developed / is in a work-in-progress state. The code is available here: https://github.com/code54/cobertura-chocolate *Why the changes? / Objectives:* - tests should run once. Due to original Cobertura design, users were forced to run instrumentation and tests immediately, and later run tests again to see if something was broken. - expose more data. Ex.: expose coverage thresholds and coverage data on reports, allow to build custom metrics. Serialize data in a readable format. - decouple from Ant and provide a DSL to set parameters, run code instrumentation and provide programatic access to results - provide means to add new metrics - provide means to support multiple JVM languages - provide a report where all metrics, thresholds and sourcelines are stored. This way we no longer need to recompile/instrument and test to generate a report and no longer depend on source code: represents code's snapshot. New reports in different formats can be created using it. *What is done:* - migrated Cobertura to Git and Maven, - removed static initialization - move away from Ant tasks and provided a DSL that wrapps them. This allows us to run compilation, instrumentation, tests and reports creation separately (some tests were created for this: see CodeInstrumentationIntegrationTest). Tests run once! - provide xml serialization for ProjectData: serialized data is now human readable. - provide an interface so that users can create their own metrics. This are loaded by reflection. - separate ProjectData from reporting layer. A GenericReport is created from ProjectData metrics. Will also include custom metrics results. Introducing GenericReport we no longer -- require compilation/instrumentation/test steps to export to different report formats. GenericReport stores a snapshot. -- depend on ProjectData -- depend on project source files Serializing GenericReport, we should be able to produce any reports. All code information (Project, Package, Sourcefile, Class, Method, Line) is treated as a graph. We provide filters and criterias to query it. Looking at the code, you'll notice that most changes do not affect the existing Cobertura code, but there is much work being done on top of it. *Does the code contain bugs?* Yes, it does. If you find some, please provide feedback :) If you think this is an interesting idea, consider contributing some code. *Known limitations / issues:* When using the DSL - currently we need to resolve how do we deal with thresholds on GenericReport - currently there is a bug around including source lines into GenericReport. If you run CodeInstrumentationIntegrationTest::testExportXml() you'll get an xml report, but no source lines will be exported. - html report needs to be fixed - we are not handling war/jar/ear instrumentation - we are not supporting old xml formats from the DSL. This limitations are TODOs, and will be handled in a future. *Next steps* - add more tests - finish the GenericReport implementation regarding thresholds and fix the code lines bug - support old xml formats - fix html format - develop report builders for other JVM languages .... What are your thoughts about this? Jose. |
From: José M. R. <jmr...@gm...> - 2012-10-26 22:38:06
|
Hello, I've been working on some ideas for Cobertura project, and I wanted to contribute this code to it and get some feedback from the Cobertura team, if may be interested on this. This is still being developed / is in a work-in-progress state. The code is available here: https://github.com/code54/cobertura-chocolate *Why the changes? / Objectives:* - tests should run once. Due to original Cobertura design, users were forced to run instrumentation and tests immediately, and later run tests again to see if something was broken. - expose more data. Ex.: expose coverage thresholds and coverage data on reports, allow to build custom metrics. Serialize data in a readable format. - decouple from Ant and provide a DSL to set parameters, run code instrumentation and provide programatic access to results - provide means to add new metrics - provide means to support multiple JVM languages - provide a report where all metrics, thresholds and sourcelines are stored. This way we no longer need to recompile/instrument and test to generate a report and no longer depend on source code: represents code's snapshot. New reports in different formats can be created using it. *What is done:* - migrated Cobertura to Git and Maven, - removed static initialization - move away from Ant tasks and provided a DSL that wrapps them. This allows us to run compilation, instrumentation, tests and reports creation separately (some tests were created for this: see CodeInstrumentationIntegrationTest). Tests run once! - provide xml serialization for ProjectData: serialized data is now human readable. - provide an interface so that users can create their own metrics. This are loaded by reflection. - separate ProjectData from reporting layer. A GenericReport is created from ProjectData metrics. Will also include custom metrics results. Introducing GenericReport we no longer -- require compilation/instrumentation/test steps to export to different report formats. GenericReport stores a snapshot. -- depend on ProjectData -- depend on project source files Serializing GenericReport, we should be able to produce any reports. All code information (Project, Package, Sourcefile, Class, Method, Line) is treated as a graph. We provide filters and criterias to query it. Looking at the code, you'll notice that most changes do not affect the existing Cobertura code, but there is much work being done on top of it. *Does the code contain bugs?* Yes, it does. If you find some, please provide feedback :) If you think this is an interesting idea, consider contributing some code. *Known limitations / issues:* When using the DSL - currently we need to resolve how do we deal with thresholds on GenericReport - currently there is a bug around including source lines into GenericReport. If you run CodeInstrumentationIntegrationTest::testExportXml() you'll get an xml report, but no source lines will be exported. - html report needs to be fixed - we are not handling war/jar/ear instrumentation - we are not supporting old xml formats from the DSL. This limitations are TODOs, and will be handled in a future. *Next steps* - add more tests - finish the GenericReport implementation regarding thresholds and fix the code lines bug - support old xml formats - fix html format - develop report builders for other JVM languages .... What are your thoughts about this? Jose. |
From: John W. L. <Joh...@sa...> - 2012-10-16 14:01:01
|
It is best to base them off of the ptab_v2_0 branch. From: Daniel Wainwright [mailto:da...@li...] Sent: Monday, October 15, 2012 11:19 PM To: cob...@li... Subject: [Cobertura-devel] develop on trunk or ptab_v2_0 I notice that the branch ptab_v2_0 has had more recent development than the Cobertura trunk, is this planned to be merged into the next release? If I want to submit patches, which would be the best branch to base them off? Daniel |
From: Jeremy T. <jth...@us...> - 2012-10-16 12:16:08
|
I wholeheartedly agree. I know I'm not active on Cobertura any more, but I love GitHub. On Mon, Oct 15, 2012 at 4:49 PM, John W. Lewis <Joh...@sa...> wrote: > ** ** > > Steve Christou suggested that the Cobertura code be moved to github to > “allow for more people to commit patches/fixes for certain items?” I think > that is a good idea, but I want to see if anyone has an objection to that. > **** > > ** ** > > John**** > > ** ** > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > |
From: Daniel W. <da...@li...> - 2012-10-16 03:19:47
|
I notice that the branch ptab_v2_0 has had more recent development than the Cobertura trunk, is this planned to be merged into the next release? If I want to submit patches, which would be the best branch to base them off? Daniel |
From: KARR, D. <dk...@at...> - 2012-10-15 22:20:40
|
> -----Original Message----- > From: Steve Christou [mailto:sch...@gm...] > Sent: Monday, October 15, 2012 3:00 PM > To: KARR, DAVID > Cc: cob...@li... > Subject: Re: [Cobertura-devel] Confused about what Maven goals I should > be using > > Sorry, I forgot to attach my message. (sensitive mouse pad). > > By default I don't believe the clean or check goals are bound to > anything. How does your pom.xml file look like? (you don't need to > show everything just the parts you believe are redundant). The check > goal is designed for making sure that code coverage does not fall > below a certain percentage. A lot of people use it if they have to > guarantee a code coverage above 80% before doing a release, so they > use the check option to make sure they don't go below that number. I thought I essentially described what I was doing, but here it is in detail: <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>cobertura-maven-plugin</artifactId> <version>2.5.1</version> <configuration> <instrumentation> </instrumentation> <check> <branchRate>0</branchRate> <lineRate>0</lineRate> <haltOnFailure>true</haltOnFailure> <totalBranchRate>0</totalBranchRate> <totalLineRate>0</totalLineRate> <packageLineRate>0</packageLineRate> <packageBranchRate>0</packageBranchRate> <regexes> </regexes> </check> <formats> <format>html</format> <format>xml</format> </formats> </configuration> <executions> <execution> <id>prepare</id> <phase>prepare-package</phase> <goals> <goal>clean</goal> <goal>check</goal> </goals> </execution> <execution> <id>package</id> <phase>package</phase> <goals> <goal>cobertura</goal> </goals> </execution> </executions> </plugin> And in the "reporting" section, I have this: <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>cobertura-maven-plugin</artifactId> <version>2.5.1</version> </plugin> I eventually plan on increasing the thresholds larger than zero, so I will need the "check" goal. I assume the "cobertura" goal is what does the actual instrumentation. However, I think the advice I saw said to do this in the "package" phase, which I think comes after the "test" phase, which doesn't make sense to me. > On Mon, Oct 15, 2012 at 4:50 PM, Steve Christou <sch...@gm...> > wrote: > > On Mon, Oct 15, 2012 at 3:18 PM, KARR, DAVID <dk...@at...> wrote: > >> I'm a little confused about what Maven goals from the Cobertura > plugin I should be using. > >> > >> I've bound the "clean" and "check" goals to the "prepare-package" > phase, and I've bound the "cobertura" goal to the "package" phase. I > thought I found advice that specified these bindings. > >> > >> The Usage page for the plugin doesn't go into this much detail. It > talks about the "clean" and "check" goals, but it doesn't specify a > phase to bind to. Should I remove the "phase" elements? What phases > are they bound to if I don't include them? > >> > >> I appear to be getting valid Cobertura reports, but I'm wondering if > I'm doing something additional that's not required, or is redundant. > >> > >> -------------------------------------------------------------------- > ---------- > >> Don't let slow site performance ruin your business. Deploy New Relic > APM > >> Deploy New Relic app performance management and know exactly > >> what is happening inside your Ruby, Python, PHP, Java, and .NET app > >> Try New Relic at no cost today and get our sweet Data Nerd shirt > too! > >> http://p.sf.net/sfu/newrelic-dev2dev > >> _______________________________________________ > >> Cobertura-devel mailing list > >> Cob...@li... > >> https://lists.sourceforge.net/lists/listinfo/cobertura-devel |
From: Steve C. <sch...@gm...> - 2012-10-15 22:00:09
|
Sorry, I forgot to attach my message. (sensitive mouse pad). By default I don't believe the clean or check goals are bound to anything. How does your pom.xml file look like? (you don't need to show everything just the parts you believe are redundant). The check goal is designed for making sure that code coverage does not fall below a certain percentage. A lot of people use it if they have to guarantee a code coverage above 80% before doing a release, so they use the check option to make sure they don't go below that number. On Mon, Oct 15, 2012 at 4:50 PM, Steve Christou <sch...@gm...> wrote: > On Mon, Oct 15, 2012 at 3:18 PM, KARR, DAVID <dk...@at...> wrote: >> I'm a little confused about what Maven goals from the Cobertura plugin I should be using. >> >> I've bound the "clean" and "check" goals to the "prepare-package" phase, and I've bound the "cobertura" goal to the "package" phase. I thought I found advice that specified these bindings. >> >> The Usage page for the plugin doesn't go into this much detail. It talks about the "clean" and "check" goals, but it doesn't specify a phase to bind to. Should I remove the "phase" elements? What phases are they bound to if I don't include them? >> >> I appear to be getting valid Cobertura reports, but I'm wondering if I'm doing something additional that's not required, or is redundant. >> >> ------------------------------------------------------------------------------ >> Don't let slow site performance ruin your business. Deploy New Relic APM >> Deploy New Relic app performance management and know exactly >> what is happening inside your Ruby, Python, PHP, Java, and .NET app >> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >> http://p.sf.net/sfu/newrelic-dev2dev >> _______________________________________________ >> Cobertura-devel mailing list >> Cob...@li... >> https://lists.sourceforge.net/lists/listinfo/cobertura-devel |
From: Steve C. <sch...@gm...> - 2012-10-15 21:50:15
|
On Mon, Oct 15, 2012 at 3:18 PM, KARR, DAVID <dk...@at...> wrote: > I'm a little confused about what Maven goals from the Cobertura plugin I should be using. > > I've bound the "clean" and "check" goals to the "prepare-package" phase, and I've bound the "cobertura" goal to the "package" phase. I thought I found advice that specified these bindings. > > The Usage page for the plugin doesn't go into this much detail. It talks about the "clean" and "check" goals, but it doesn't specify a phase to bind to. Should I remove the "phase" elements? What phases are they bound to if I don't include them? > > I appear to be getting valid Cobertura reports, but I'm wondering if I'm doing something additional that's not required, or is redundant. > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel |