Menu
▾
▴
cobertura-patches — Automated emails from our patch tracking system
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(12) |
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(1) |
Mar
(5) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(13) |
Dec
(2) |
| 2009 |
Jan
(21) |
Feb
(3) |
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(14) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(5) |
Dec
(1) |
| 2010 |
Jan
(1) |
Feb
(8) |
Mar
(4) |
Apr
|
May
|
Jun
(1) |
Jul
(9) |
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2011 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(6) |
Dec
(1) |
| 2013 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2011-02-10 06:21:32
|
Patches item #3177111, was opened at 2011-02-10 01:21 Message generated for change (Tracker Item Submitted) made by charles_honton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3177111&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Charles Honton (charles_honton) Assigned to: Nobody/Anonymous (nobody) Summary: add JMX interface to write coverage data Initial Comment: patch to feature request ID: 1925513 JMX is often the best way to control a component in a managed environment. This interface could be extended for more control messages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3177111&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2011-01-07 06:00:24
|
Patches item #3152767, was opened at 2011-01-07 06:00 Message generated for change (Tracker Item Submitted) made by qxo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3152767&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: qxo (qxo) Assigned to: Nobody/Anonymous (nobody) Summary: fixed for java source encoding issue Initial Comment: java file encoding=UTF-8 file.encoding = GBK the same reason with: http://sourceforge.net/tracker/?func=detail&aid=2968676&group_id=130558&atid=720017 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3152767&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-12-16 20:45:56
|
Patches item #3138755, was opened at 2010-12-16 15:45 Message generated for change (Tracker Item Submitted) made by chonton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3138755&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Charles Honton (chonton) Assigned to: Nobody/Anonymous (nobody) Summary: Do not instrument synthetic methods Initial Comment: Generics introduce synthetic bridge methods which are not intended to be directly called. When instrumented, it looks like a line 0 method which is never called. The attached patch prevents any synthetic method from being called ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3138755&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-11-17 11:20:02
|
Patches item #3110640, was opened at 2010-11-17 12:20 Message generated for change (Tracker Item Submitted) made by zombi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3110640&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: g zombi (zombi) Assigned to: Nobody/Anonymous (nobody) Summary: Ability to disable shutdown hook Initial Comment: I'm trying to use cobertura in google app engine SDK, but it is using a security manager, which prevents creating threads. However cobertura tries to install a shutdown hook, in a static class initializer. With the attached patch, this exception wont be a lethal strike againt the usage of cobertura BR ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3110640&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-08-23 21:11:46
|
Patches item #3051822, was opened at 2010-08-23 16:11 Message generated for change (Tracker Item Submitted) made by chenis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3051822&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kenneth Chenis (chenis) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up FileFinder for in-jar source access Initial Comment: This patch adds a cache/map that creates a cross reference for all the classes to their corresponding jar files on the first pass. This way each subsequent request for a source file does not have to scan all the jar files in the directories. This made for a significant performance enhancement on our system, and report generation went from over 10 minutes to under 2 minutes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3051822&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-08-21 02:56:38
|
Patches item #1255463, was opened at 2005-08-10 04:09 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1255463&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: James Seigel (cgul) Assigned to: Nobody/Anonymous (nobody) Summary: Small cleanup of SaveTimer.java Initial Comment: It looks like SaveTimer was changed a while back to use a shutdown hook instead of timed saves for the saving of the instrument file. I cleaned up some of the commented out code and changed the name of the class to better reflect its intent. SaveTimer.java removed Cleanup.zip has the diffs and the new file in it. Just doing some cleanup as I familiarize myself with more of the codebase. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-08-21 02:56 Message: uySBnI <a href="http://nlkwfjjjcijb.com/">nlkwfjjjcijb</a>, [url=http://yxrfbpccvkao.com/]yxrfbpccvkao[/url], [link=http://ysernlkszyrz.com/]ysernlkszyrz[/link], http://etrffhlovmul.com/ ---------------------------------------------------------------------- Comment By: James Seigel (cgul) Date: 2005-09-02 13:10 Message: Logged In: YES user_id=1282699 Will look into it. just getting back from holidays. ---------------------------------------------------------------------- Comment By: Grzegorz Lukasik (hauserx) Date: 2005-08-27 14:56 Message: Logged In: YES user_id=1216999 James, will you implement it? ---------------------------------------------------------------------- Comment By: James Seigel (cgul) Date: 2005-08-11 12:35 Message: Logged In: YES user_id=1282699 Sounds good. Cheers James ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-08-11 04:01 Message: Logged In: YES user_id=20979 Nope, no such document. I've been happy just using the various trackers at sourceforge. As for the SaveTimer... It DID originally have the ability to save after an interval, but I removed it at some point. I don't really have an opinion either way. On the one hand, I don't really like adding features that people haven't asked for/might not use, but on the other hand, it IS something that could be extremely useful in some circumstances. Probably better to add the ability to save every x number of seconds. ---------------------------------------------------------------------- Comment By: James Seigel (cgul) Date: 2005-08-10 15:22 Message: Logged In: YES user_id=1282699 Sounds good Grzegorz. Cheers James ---------------------------------------------------------------------- Comment By: Grzegorz Lukasik (hauserx) Date: 2005-08-10 15:18 Message: Logged In: YES user_id=1216999 There is probably no such a document. When Mark will be back maybe he will say something more. ---------------------------------------------------------------------- Comment By: James Seigel (cgul) Date: 2005-08-10 14:42 Message: Logged In: YES user_id=1282699 Sounds like an interesting approach. I will have a look. Is there a vision/todo document kicking around describing where we want to go with the development/features? Cheers James. ---------------------------------------------------------------------- Comment By: Grzegorz Lukasik (hauserx) Date: 2005-08-10 14:33 Message: Logged In: YES user_id=1216999 Maybe we can go the other way, and implement SaveTimer properly. Let's say that if property net.sourceforge.cobertura.flushtime is set, then new thread is created that flushes data periodically. It can be useful for server applications where people use hot deploy feature and server cannot be shutdowned (I know about one such case). Or reports could be generated during tests run. Just a proposition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1255463&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-07-19 06:18:42
|
Patches item #3031444, was opened at 2010-07-19 01:18 Message generated for change (Tracker Item Submitted) made by paulbenedict You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3031444&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Benedict (paulbenedict) Assigned to: Nobody/Anonymous (nobody) Summary: Option to disable source xref Initial Comment: John, I am providing a patch for feature request #3028843. This is something I highly need too. Added a new --showcode option (defaults to true) so that source code can be turned off in HTML generation. I tested the patch and looks good. Please re-verify the ant task execution though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3031444&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-07-17 16:23:36
|
Patches item #3010530, was opened at 2010-06-02 09:03 Message generated for change (Comment added) made by tcsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3010530&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Tad E. Smith (tcsmith) Assigned to: John Lewis (lewijw) Summary: Ignore trivial methods & methods with "ignore" annotation Initial Comment: This is a patch to the 1.9.4.1 baseline. It adds 2 new switches: --ignoreTrivial and --ignoreMethodAnnotation. The --ignoreTrivial switch forces Cobertura to ignore the following in the coverage report. Getter methods that simply read a class field. Setter methods that set a class field. Constructors that only set class fields and call a super class constructor. The --ignoreMethodAnnotation is used to specify an annotation that, when present on a method, will force Cobertura to ignore the method in the coverage report. We also generate our getters and setters (as well as many constructors) using Eclipse. We don't want to spend time ensuring generated methods are covered by a JUnit test. (We trust the code generator otherwise we wouldn't use it.) On my project, we also use Eclipse to generate toString(), equals(), and hashCode() method. We put a "generated" annotation on these methods. Using these switches we are able to filter out the "noise" of generated methods in the coverage report and focus our attention on areas of the code that were written by developers. (Note: This is not a mechanism to boost coverage %, because in many cases the coverage % goes down when these methods are removed from the report.) Thanks, -- Tad ---------------------------------------------------------------------- Comment By: Tad E. Smith (tcsmith) Date: 2010-07-17 10:23 Message: I discovered a bug in the patch I submitted. The FirstPassMethInstrumenter.visitAnnotation() method is incorrect. Here is the corrected method: public AnnotationVisitor visitAnnotation(String desc, boolean visible) { // We need to convert desc so that it contains a fully-qualified classname. // Example: // @java.lang.Override --> passed in as this: "Ljava/lang/Override;" String annotationDesc = desc.replace('/', '.'); // Check to see if this annotation is one of the ones that we use to // trigger us to ignore this method for(Iterator it = ignoreMethodAnnotations.iterator(); it.hasNext();) { String ignoredAnnotation = (String)it.next(); if(annotationDesc.contains(ignoredAnnotation)) { ignored = true; break; } } return super.visitAnnotation(desc, visible); } ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2010-07-08 16:15 Message: It appears the ignoreTrivial functionality is Scott Frederick's from patch 1576631 (as Tad mentions in patch 2035169). The ignoreMethodAnnotation appears to be Tad's original work although it is similar to the idea in patch 2009489 where a regex was used instead of an annotation. Committed revision 730. Thanks Tad and Scott! ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2010-07-08 15:53 Message: This patch is an update of this patch: https://sourceforge.net/tracker/?func=detail&aid=2035169&group_id=130558&atid=720017 ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2010-07-07 19:12 Message: I intend on applying all of this patch. I have added the ignoreTrivial functionality first. It is revision 729. I created a functional test that gives a good idea of what is considered trivial: http://cobertura.svn.sourceforge.net/viewvc/cobertura/trunk/cobertura/test/net/sourceforge/cobertura/test/IgnoreTrivialFunctionalTest.groovy?revision=729&view=markup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3010530&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-07-08 22:15:06
|
Patches item #3010530, was opened at 2010-06-02 10:03 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3010530&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Tad E. Smith (tcsmith) Assigned to: John Lewis (lewijw) Summary: Ignore trivial methods & methods with "ignore" annotation Initial Comment: This is a patch to the 1.9.4.1 baseline. It adds 2 new switches: --ignoreTrivial and --ignoreMethodAnnotation. The --ignoreTrivial switch forces Cobertura to ignore the following in the coverage report. Getter methods that simply read a class field. Setter methods that set a class field. Constructors that only set class fields and call a super class constructor. The --ignoreMethodAnnotation is used to specify an annotation that, when present on a method, will force Cobertura to ignore the method in the coverage report. We also generate our getters and setters (as well as many constructors) using Eclipse. We don't want to spend time ensuring generated methods are covered by a JUnit test. (We trust the code generator otherwise we wouldn't use it.) On my project, we also use Eclipse to generate toString(), equals(), and hashCode() method. We put a "generated" annotation on these methods. Using these switches we are able to filter out the "noise" of generated methods in the coverage report and focus our attention on areas of the code that were written by developers. (Note: This is not a mechanism to boost coverage %, because in many cases the coverage % goes down when these methods are removed from the report.) Thanks, -- Tad ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2010-07-08 17:15 Message: It appears the ignoreTrivial functionality is Scott Frederick's from patch 1576631 (as Tad mentions in patch 2035169). The ignoreMethodAnnotation appears to be Tad's original work although it is similar to the idea in patch 2009489 where a regex was used instead of an annotation. Committed revision 730. Thanks Tad and Scott! ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2010-07-08 16:53 Message: This patch is an update of this patch: https://sourceforge.net/tracker/?func=detail&aid=2035169&group_id=130558&atid=720017 ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2010-07-07 20:12 Message: I intend on applying all of this patch. I have added the ignoreTrivial functionality first. It is revision 729. I created a functional test that gives a good idea of what is considered trivial: http://cobertura.svn.sourceforge.net/viewvc/cobertura/trunk/cobertura/test/net/sourceforge/cobertura/test/IgnoreTrivialFunctionalTest.groovy?revision=729&view=markup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3010530&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-07-08 21:53:08
|
Patches item #3010530, was opened at 2010-06-02 10:03 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3010530&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Tad E. Smith (tcsmith) Assigned to: John Lewis (lewijw) Summary: Ignore trivial methods & methods with "ignore" annotation Initial Comment: This is a patch to the 1.9.4.1 baseline. It adds 2 new switches: --ignoreTrivial and --ignoreMethodAnnotation. The --ignoreTrivial switch forces Cobertura to ignore the following in the coverage report. Getter methods that simply read a class field. Setter methods that set a class field. Constructors that only set class fields and call a super class constructor. The --ignoreMethodAnnotation is used to specify an annotation that, when present on a method, will force Cobertura to ignore the method in the coverage report. We also generate our getters and setters (as well as many constructors) using Eclipse. We don't want to spend time ensuring generated methods are covered by a JUnit test. (We trust the code generator otherwise we wouldn't use it.) On my project, we also use Eclipse to generate toString(), equals(), and hashCode() method. We put a "generated" annotation on these methods. Using these switches we are able to filter out the "noise" of generated methods in the coverage report and focus our attention on areas of the code that were written by developers. (Note: This is not a mechanism to boost coverage %, because in many cases the coverage % goes down when these methods are removed from the report.) Thanks, -- Tad ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2010-07-08 16:53 Message: This patch is an update of this patch: https://sourceforge.net/tracker/?func=detail&aid=2035169&group_id=130558&atid=720017 ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2010-07-07 20:12 Message: I intend on applying all of this patch. I have added the ignoreTrivial functionality first. It is revision 729. I created a functional test that gives a good idea of what is considered trivial: http://cobertura.svn.sourceforge.net/viewvc/cobertura/trunk/cobertura/test/net/sourceforge/cobertura/test/IgnoreTrivialFunctionalTest.groovy?revision=729&view=markup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3010530&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-07-08 18:01:29
|
Patches item #2009489, was opened at 2008-07-03 02:49 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2009489&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fabian Reichlin (fabianr) >Assigned to: John Lewis (lewijw) Summary: Exclude entire methods from instrumentation Initial Comment: Currently it is not possible to exclude entire methods from being instrumented. Rather, the ignore command just filters out method calls within custom methods themselves (e.g. logging statements within custom methods). This patch introduces a new command "ignoreMethod", which can be used from command line or ant tasks, and skips over entire methods to ignore them from Cobertura reports. In contrast to patch #1576631, the ignore statement is not limited to just setter and getter methods. For method matching, the specified ignore statement can be any substring of the actual method -- making the ignore method more powerful (e.g. .set* and .get* to ignore all setters and getters). ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2010-07-08 13:01 Message: I am about to add an --ignoreMethodAnnotation switch that is in the following patch: https://sourceforge.net/tracker/index.php?func=detail&aid=3010530&group_id=130558&atid=720017 That patch was derived from: https://sourceforge.net/tracker/index.php?func=detail&aid=2035169&group_id=130558&atid=720017 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2009489&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-07-08 17:44:58
|
Patches item #1576631, was opened at 2006-10-13 10:27 Message generated for change (Settings changed) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1576631&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Scott Frederick (scottyfred) >Assigned to: John Lewis (lewijw) Summary: Ignore trivial methods (optionally) Initial Comment: This patch implements a new feature in Cobertura that allows trivial methods (getters, setters, etc.) to be excluded from coverage metrics. This feature is useful if you follow the philosophy that trivial getters and setters "can't break" and therefore do not need unit tests. The Ant task and command-line Main accept a new option named "ignoreTrivial". If this option is set to "true", methods that match the criteria below are excluded from coverage. If the option is set to "false", then all methods are included as Cobertura does today. The criteria for deciding a method is trivial are: getters: - method name begins with "get", "is", or "has" - method accepts no arguments - method return type is non-void - method contains only bytecode instructions for getting member field values setters: - method name begins with "set" - method accepts exactly one argument - method return type is void - method contains only bytecode instructions for setting member field values initializers: - method name is "<init>" (constructors and implicit initializers) - method contains only bytecode instructions for setting member field values and calling initializer method of immediate superclass (e.g. "super();") ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2010-07-08 12:44 Message: This patch has been applied. Please see: https://sourceforge.net/tracker/index.php?func=detail&aid=3010530&group_id=130558&atid=720017 I believe that fabriziogiudici's desire for an annotation is also handled by the same patch. I will apply the rest of it soon. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-07-18 12:58 Message: Logged In: NO As first state, the criteria for excluding methods in this enhancement is much more strict than just looking for "get" or "set" in the name. Only methods that are truly trivial (only return the value of one data member or only set the value of one data member) are excluded. ---------------------------------------------------------------------- Comment By: Fabrizio Giudici (fabriziogiudici) Date: 2007-04-14 03:18 Message: Logged In: YES user_id=861031 Originator: NO Why instead don't you introduce an annotation (or a config file) to mark the methods to exclude one by one? Getter methods could be more complex than a simple "return foo": for instance in a proxy or in a decorator there is some logic inside. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1576631&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-07-08 01:17:12
|
Patches item #2035169, was opened at 2008-08-01 13:52 Message generated for change (Settings changed) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2035169&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Scott Frederick (scottyfred) >Assigned to: John Lewis (lewijw) Summary: Exclude methods from instrumentation (two for one sale) Initial Comment: This patch is a merge of two previous patches: 1576631 and 2009489. Patch 1576631 needed to be migrated from Cobertura 1.8 to 1.9, and there was significant overlap in the implementation of these two patches, so I merged them into one. There are a few use cases for ignoring entire methods when generating coverage metrics. One is to ignore getters and setters that follow the JavaBean pattern. There is usually little value in testing these methods, as their implementation is trivial and reliable. Another use case is to ignore code that is generated by another tool or technology during the build process. There are other use cases as well. These two patches are meant to address use cases like these. *** Ignore named methods *** Patch 2009489 implemented a new optional parameter to specify the names of methods which should be excluded from instrumentation. The optional parameter "ignoreMethod", which can be used from command line or ant tasks, excludes entire methods from instrumentation. For method name matching, the specified ignore statement can be any substring of the actual method -- making the ignore method more powerful (e.g. ".set*" and ".get*" to ignore all setters and getters). *** Ignore trivial methods *** Patch 1576631 implemented a new optional parameter that enables the inspection of methods to identify those methods that follow the JavaBean pattern for getters and setters, and excludes those methods from instrumentation. The Ant task and command-line Main accept a new boolean option named "ignoreTrivial". If this option is set to "true", methods that match the criteria below are excluded from coverage. If the option is set to "false", all methods are included as Cobertura does today. The criteria for deciding a method is trivial are: getters: - method name begins with "get", "is", or "has" - method accepts no arguments - method return type is non-void - method contains only bytecode instructions for getting member field values setters: - method name begins with "set" - method accepts exactly one argument - method return type is void - method contains only bytecode instructions for setting member field values initializers: - method name is "<init>" (constructors and implicit initializers) - method contains only bytecode instructions for setting member field values and calling initializer method of immediate superclass (e.g. "super();") ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2010-07-07 20:16 Message: Part of this patch has been applied. Please see: https://sourceforge.net/tracker/index.php?func=detail&aid=3010530&group_id=130558&atid=720017 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-07-10 13:19 Message: There are lots of suggested ways to control what is measured for coverage. To reiterate my requirements and motivation for this patch: - I do NOT want to specify a method name pattern for exclusion/ignoring. This leaves me open to ignoring methods that look like getters/setters but in fact are not trivial and should be tested. - I do NOT wan to annotate, otherwise decorate, or provide a list of all methods to exclude/ignore. It would be a lot of work to manually identify all the candidate methods and it would become a maintenance headache. - I DO want the tool to automatically identify methods that are truly trivial, using a very tight and conservative set of heuristics (as detailed in the patch description). In other words, in the case of trivial getters and setters I don't care to have complete control over what is excluded, I want the tool to help me out and allow me to do less configuration work to get the desires outcome. ---------------------------------------------------------------------- Comment By: Ho Tri Bao (hotribao) Date: 2008-12-09 11:33 Message: Well, I totally agree with the point of scottyfred: "it is dangerous to exclude getters and setters from coverage metrics based only on the name of the method". But let me state it in a different way: "It is dangerous to exclude methods from coverage metrics based on method name pattern. AND we have no control on what were excluded" But we have to agree that this is a real need. I submitted a patch which solve these issues: - Excluded methods (I called it ignored methods) can be enumerated, wildcard is supported (I think using wildcard is simply enough for all people) - Excluded methods are reported (easy to realize) on source code view of a class - Risky Excluded methods are also reported: risky excluded methods are the ones that are complex but were excluded So, you are fully control what were excluded. Since the feature uses complexity calculation. And there is a bug for this in JDK 1.5+. This bug was also fixed in this patch. There are more features included in that patch also, such as top project risks (risky classes, risky methods) The patch is here: https://sourceforge.net/tracker/index.php?func=detail&aid=2353196&group_id=130558&atid=720017 ---------------------------------------------------------------------- Comment By: Scott Frederick (scottyfred) Date: 2008-08-01 14:03 Message: Logged In: YES user_id=294534 Originator: YES So, which new option to use? This has been debated in the descriptions and comments of the related patches. In my opinion, it is dangerous to exclude getters and setters from coverage metrics based only on the name of the method. Methods that start with "get" can contain calculations, and methods that start with "set" can have side-effects beyond just setting the value of a single data member. These "non-trivial" getters and setters (which probably violate the JavaBean pattern) should be tested, and should not be excluded from coverage metrics. The "ignoreTrivial" enhancement in this patch goes beyond inspecting just the method name, to inspect the method signature (to match only methods that follow the JavaBean signature pattern) and the byte code contained in the method (to match only methods that get or set the value of a single data member as appropriate). If you have some other way (like static code checking) to enforce that methods named with "get" and "set" follow a pattern, the excluding coverage by name might work just file. Otherwise, I think "ignoreTrivial" comes a lot closer to what you want for this use case than simple name matching does. This was the original thinking behind patch 1576631. That's just my opinion; your team and your project are almost certainly different than mine. Two options are provided here, other patches have been submitted to support annotation-based exclusion. Use whichever method works for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2035169&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-07-08 01:16:44
|
Patches item #2035169, was opened at 2008-08-01 13:52 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2035169&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Scott Frederick (scottyfred) Assigned to: Nobody/Anonymous (nobody) Summary: Exclude methods from instrumentation (two for one sale) Initial Comment: This patch is a merge of two previous patches: 1576631 and 2009489. Patch 1576631 needed to be migrated from Cobertura 1.8 to 1.9, and there was significant overlap in the implementation of these two patches, so I merged them into one. There are a few use cases for ignoring entire methods when generating coverage metrics. One is to ignore getters and setters that follow the JavaBean pattern. There is usually little value in testing these methods, as their implementation is trivial and reliable. Another use case is to ignore code that is generated by another tool or technology during the build process. There are other use cases as well. These two patches are meant to address use cases like these. *** Ignore named methods *** Patch 2009489 implemented a new optional parameter to specify the names of methods which should be excluded from instrumentation. The optional parameter "ignoreMethod", which can be used from command line or ant tasks, excludes entire methods from instrumentation. For method name matching, the specified ignore statement can be any substring of the actual method -- making the ignore method more powerful (e.g. ".set*" and ".get*" to ignore all setters and getters). *** Ignore trivial methods *** Patch 1576631 implemented a new optional parameter that enables the inspection of methods to identify those methods that follow the JavaBean pattern for getters and setters, and excludes those methods from instrumentation. The Ant task and command-line Main accept a new boolean option named "ignoreTrivial". If this option is set to "true", methods that match the criteria below are excluded from coverage. If the option is set to "false", all methods are included as Cobertura does today. The criteria for deciding a method is trivial are: getters: - method name begins with "get", "is", or "has" - method accepts no arguments - method return type is non-void - method contains only bytecode instructions for getting member field values setters: - method name begins with "set" - method accepts exactly one argument - method return type is void - method contains only bytecode instructions for setting member field values initializers: - method name is "<init>" (constructors and implicit initializers) - method contains only bytecode instructions for setting member field values and calling initializer method of immediate superclass (e.g. "super();") ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2010-07-07 20:16 Message: Part of this patch has been applied. Please see: https://sourceforge.net/tracker/index.php?func=detail&aid=3010530&group_id=130558&atid=720017 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-07-10 13:19 Message: There are lots of suggested ways to control what is measured for coverage. To reiterate my requirements and motivation for this patch: - I do NOT want to specify a method name pattern for exclusion/ignoring. This leaves me open to ignoring methods that look like getters/setters but in fact are not trivial and should be tested. - I do NOT wan to annotate, otherwise decorate, or provide a list of all methods to exclude/ignore. It would be a lot of work to manually identify all the candidate methods and it would become a maintenance headache. - I DO want the tool to automatically identify methods that are truly trivial, using a very tight and conservative set of heuristics (as detailed in the patch description). In other words, in the case of trivial getters and setters I don't care to have complete control over what is excluded, I want the tool to help me out and allow me to do less configuration work to get the desires outcome. ---------------------------------------------------------------------- Comment By: Ho Tri Bao (hotribao) Date: 2008-12-09 11:33 Message: Well, I totally agree with the point of scottyfred: "it is dangerous to exclude getters and setters from coverage metrics based only on the name of the method". But let me state it in a different way: "It is dangerous to exclude methods from coverage metrics based on method name pattern. AND we have no control on what were excluded" But we have to agree that this is a real need. I submitted a patch which solve these issues: - Excluded methods (I called it ignored methods) can be enumerated, wildcard is supported (I think using wildcard is simply enough for all people) - Excluded methods are reported (easy to realize) on source code view of a class - Risky Excluded methods are also reported: risky excluded methods are the ones that are complex but were excluded So, you are fully control what were excluded. Since the feature uses complexity calculation. And there is a bug for this in JDK 1.5+. This bug was also fixed in this patch. There are more features included in that patch also, such as top project risks (risky classes, risky methods) The patch is here: https://sourceforge.net/tracker/index.php?func=detail&aid=2353196&group_id=130558&atid=720017 ---------------------------------------------------------------------- Comment By: Scott Frederick (scottyfred) Date: 2008-08-01 14:03 Message: Logged In: YES user_id=294534 Originator: YES So, which new option to use? This has been debated in the descriptions and comments of the related patches. In my opinion, it is dangerous to exclude getters and setters from coverage metrics based only on the name of the method. Methods that start with "get" can contain calculations, and methods that start with "set" can have side-effects beyond just setting the value of a single data member. These "non-trivial" getters and setters (which probably violate the JavaBean pattern) should be tested, and should not be excluded from coverage metrics. The "ignoreTrivial" enhancement in this patch goes beyond inspecting just the method name, to inspect the method signature (to match only methods that follow the JavaBean signature pattern) and the byte code contained in the method (to match only methods that get or set the value of a single data member as appropriate). If you have some other way (like static code checking) to enforce that methods named with "get" and "set" follow a pattern, the excluding coverage by name might work just file. Otherwise, I think "ignoreTrivial" comes a lot closer to what you want for this use case than simple name matching does. This was the original thinking behind patch 1576631. That's just my opinion; your team and your project are almost certainly different than mine. Two options are provided here, other patches have been submitted to support annotation-based exclusion. Use whichever method works for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2035169&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-07-08 01:12:54
|
Patches item #3010530, was opened at 2010-06-02 10:03 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3010530&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Tad E. Smith (tcsmith) >Assigned to: John Lewis (lewijw) Summary: Ignore trivial methods & methods with "ignore" annotation Initial Comment: This is a patch to the 1.9.4.1 baseline. It adds 2 new switches: --ignoreTrivial and --ignoreMethodAnnotation. The --ignoreTrivial switch forces Cobertura to ignore the following in the coverage report. Getter methods that simply read a class field. Setter methods that set a class field. Constructors that only set class fields and call a super class constructor. The --ignoreMethodAnnotation is used to specify an annotation that, when present on a method, will force Cobertura to ignore the method in the coverage report. We also generate our getters and setters (as well as many constructors) using Eclipse. We don't want to spend time ensuring generated methods are covered by a JUnit test. (We trust the code generator otherwise we wouldn't use it.) On my project, we also use Eclipse to generate toString(), equals(), and hashCode() method. We put a "generated" annotation on these methods. Using these switches we are able to filter out the "noise" of generated methods in the coverage report and focus our attention on areas of the code that were written by developers. (Note: This is not a mechanism to boost coverage %, because in many cases the coverage % goes down when these methods are removed from the report.) Thanks, -- Tad ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2010-07-07 20:12 Message: I intend on applying all of this patch. I have added the ignoreTrivial functionality first. It is revision 729. I created a functional test that gives a good idea of what is considered trivial: http://cobertura.svn.sourceforge.net/viewvc/cobertura/trunk/cobertura/test/net/sourceforge/cobertura/test/IgnoreTrivialFunctionalTest.groovy?revision=729&view=markup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3010530&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-06-02 15:03:49
|
Patches item #3010530, was opened at 2010-06-02 09:03 Message generated for change (Tracker Item Submitted) made by tcsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3010530&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tad E. Smith (tcsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Ignore trivial methods & methods with "ignore" annotation Initial Comment: This is a patch to the 1.9.4.1 baseline. It adds 2 new switches: --ignoreTrivial and --ignoreMethodAnnotation. The --ignoreTrivial switch forces Cobertura to ignore the following in the coverage report. Getter methods that simply read a class field. Setter methods that set a class field. Constructors that only set class fields and call a super class constructor. The --ignoreMethodAnnotation is used to specify an annotation that, when present on a method, will force Cobertura to ignore the method in the coverage report. We also generate our getters and setters (as well as many constructors) using Eclipse. We don't want to spend time ensuring generated methods are covered by a JUnit test. (We trust the code generator otherwise we wouldn't use it.) On my project, we also use Eclipse to generate toString(), equals(), and hashCode() method. We put a "generated" annotation on these methods. Using these switches we are able to filter out the "noise" of generated methods in the coverage report and focus our attention on areas of the code that were written by developers. (Note: This is not a mechanism to boost coverage %, because in many cases the coverage % goes down when these methods are removed from the report.) Thanks, -- Tad ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3010530&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-03-19 09:58:07
|
Patches item #2973067, was opened at 2010-03-19 18:55 Message generated for change (Settings changed) made by kawasima You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2973067&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Kawasima Yositaka (kawasima) Assigned to: Nobody/Anonymous (nobody) Summary: append HasBeenInstrumented to generic class signature Initial Comment: Cobertura instrumentation for generic class looks like incomplete. For Instrumented generic class, getGenericInterfaces() returns a result different from getInterfaces(). This patch fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2973067&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-03-19 09:55:50
|
Patches item #2973067, was opened at 2010-03-19 18:55 Message generated for change (Tracker Item Submitted) made by kawasima You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2973067&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kawasima Yositaka (kawasima) Assigned to: Nobody/Anonymous (nobody) Summary: append HasBeenInstrumented to generic class signature Initial Comment: Cobertura instrumentation for generic class looks like incomplete. For Instrumented generic class, getGenericInterfaces() returns a result different from getInterfaces(). This patch fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2973067&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-03-19 09:33:10
|
Patches item #2973056, was opened at 2010-03-19 18:33 Message generated for change (Tracker Item Submitted) made by kawasima You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2973056&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kawasima Yositaka (kawasima) Assigned to: Nobody/Anonymous (nobody) Summary: append HasBeenInstrumented to generic class signature Initial Comment: Cobertura instrumentation for generic class looks like incomplete. For Instrumented generic class, getGenericInterfaces() returns a result different from getInterfaces(). This patch fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2973056&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-03-11 13:44:02
|
Patches item #2968676, was opened at 2010-03-11 13:44 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2968676&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: cobertura-report:ant report have some i18n(encoding) issue Initial Comment: cobertura-report] net.sourceforge.cobertura.javancss.parser.TokenMgrError: Lexical error at line 13, column 50. Encountered: "\n" (10), after : "\"\u942a\u4f78\u53d5\u9359\ufffd);" [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParserTokenManager.getNextToken(JavaParserTokenManager.java:2078) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.jj_scan_token(JavaParser.java:10181) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.jj_3R_198(JavaParser.java:8524) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.jj_3R_178(JavaParser.java:8924) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.jj_3R_151(JavaParser.java:8901) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.jj_3R_102(JavaParser.java:8960) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.jj_3_25(JavaParser.java:9977) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.jj_2_25(JavaParser.java:5999) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.Expression(JavaParser.java:2762) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.ArgumentList(JavaParser.java:3626) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.Arguments(JavaParser.java:3604) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.PrimarySuffix(JavaParser.java:3515) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.PrimaryExpression(JavaParser.java:3396) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.StatementExpression(JavaParser.java:4083) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.Statement(JavaParser.java:3808) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.BlockStatement(JavaParser.java:3997) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.Block(JavaParser.java:3947) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.Initializer(JavaParser.java:2528) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.ClassBodyDeclaration(JavaParser.java:1064) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.ClassBody(JavaParser.java:941) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.UnmodifiedClassDeclaration(JavaParser.java:854) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.ClassDeclaration(JavaParser.java:761) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.TypeDeclaration(JavaParser.java:608) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.CompilationUnit(JavaParser.java:353) [cobertura-report] at net.sourceforge.cobertura.javancss.parser.JavaParser.parse(JavaParser.java:137) [cobertura-report] at net.sourceforge.cobertura.javancss.Javancss._measureSource(Javancss.java:256) [cobertura-report] at net.sourceforge.cobertura.javancss.Javancss._measureRoot(Javancss.java:339) [cobertura-report] at net.sourceforge.cobertura.javancss.Javancss.<init>(Javancss.java:419) [cobertura-report] Lexical error at line 13, column 50. Encountered: "\n" (10), after : "\"\u942a\u4f78\u53d5\u9359\ufffd);" [cobertura-report] Report time: 1747ms [cobertura-report] at net.sourceforge.cobertura.reporting.ComplexityCalculator.getCCNForPackageInternal(ComplexityCalculator.java:194) [cobertura-report] at net.sourceforge.cobertura.reporting.ComplexityCalculator.getCCNForProject(ComplexityCalculator.java:164) [cobertura-report] at net.sourceforge.cobertura.reporting.xml.XMLReport.<init>(XMLReport.java:80) [cobertura-report] at net.sourceforge.cobertura.reporting.Main.parseArguments(Main.java:107) [cobertura-report] at net.sourceforge.cobertura.reporting.Main.main(Main.java:174) [cobertura-check] Cobertura 1.9.4.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2968676&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-02-15 16:36:12
|
Patches item #2950088, was opened at 2010-02-11 18:34 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2950088&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Piotr Tabor (ptab) Assigned to: John Lewis (lewijw) Summary: Patch to performance patch (2948696) Initial Comment: There was a concurrency bug in TouchCollector.java file provided in the #2948696 patch. I've created the issue as not-logged so I have no permission to add there files. ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2010-02-15 11:36 Message: I have accepted this patch and most of the first one (2948696): https://sourceforge.net/tracker/index.php?func=detail&aid=2948696&group_id=130558&atid=720017 Very good patch! One of our tests that used to take 4.5 hours now takes 1.5! The only code I did not take was the removal of the lock code in LineData and ProjectData. I don't have a problem with removing that code in a future release, but right now, since the code is only executed in the shutdown hook, and since it is not called nearly as much, it seemed not worth the risk to remove it now. Actually, is there any need to even use "syncronized" now for those classes? I have not had a chance to look into that yet. Thank you very much! Committed revision 699 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2950088&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-02-15 16:28:48
|
Patches item #2948696, was opened at 2010-02-09 15:45 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2948696&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: John Lewis (lewijw) Summary: Performance patch Initial Comment: Makes cobertura 1.9.3 (trunk) up to 10x faster. Aggregates changes in temporary TouchCollector class (thread-safe, but lock-free) and after that applies it on real model (ProjectData) as a batch operation. ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2010-02-15 11:28 Message: Patch accepted. New files licensed as GPL/Apache. See this patch for additional comments: https://sourceforge.net/tracker/?func=detail&aid=2950088&group_id=130558&atid=720017 ---------------------------------------------------------------------- Comment By: Piotr Tabor (ptab) Date: 2010-02-10 14:34 Message: The files are licensed as GPL/Apache. You can add those headers. ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2010-02-10 14:31 Message: Piotr, there is no license in your new files. Do you mind if I add the dual GPL/Apache license that I have been adding to all new files? (Make sure you login to comment). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2948696&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-02-11 23:34:42
|
Patches item #2950088, was opened at 2010-02-12 00:34 Message generated for change (Settings changed) made by ptab You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2950088&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Piotr Tabor (ptab) >Assigned to: John Lewis (lewijw) Summary: Patch to performance patch (2948696) Initial Comment: There was a concurrency bug in TouchCollector.java file provided in the #2948696 patch. I've created the issue as not-logged so I have no permission to add there files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2950088&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-02-11 23:34:09
|
Patches item #2950088, was opened at 2010-02-12 00:34 Message generated for change (Tracker Item Submitted) made by ptab You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2950088&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Piotr Tabor (ptab) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to performance patch (2948696) Initial Comment: There was a concurrency bug in TouchCollector.java file provided in the #2948696 patch. I've created the issue as not-logged so I have no permission to add there files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2950088&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2010-02-10 19:34:22
|
Patches item #2948696, was opened at 2010-02-09 21:45 Message generated for change (Comment added) made by ptab You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2948696&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: John Lewis (lewijw) Summary: Performance patch Initial Comment: Makes cobertura 1.9.3 (trunk) up to 10x faster. Aggregates changes in temporary TouchCollector class (thread-safe, but lock-free) and after that applies it on real model (ProjectData) as a batch operation. ---------------------------------------------------------------------- Comment By: Piotr Tabor (ptab) Date: 2010-02-10 20:34 Message: The files are licensed as GPL/Apache. You can add those headers. ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2010-02-10 20:31 Message: Piotr, there is no license in your new files. Do you mind if I add the dual GPL/Apache license that I have been adding to all new files? (Make sure you login to comment). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2948696&group_id=130558 |
1 message has been excluded from this view by a project administrator.
