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...> - 2013-04-05 01:16:45
|
Patches item #2035169, was opened at 2008-08-01 11:52 Message generated for change (Comment added) made by nobody 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: Nobody/Anonymous (nobody) Date: 2013-04-04 18:16 Message: Les entreprises n'ont pas été en mesure de rivaliser sur les prix et que vous essayez d'utiliser les fonctionnalités de rivaliser au lieu et au cours des six derniers mois seulement, nous avons vu le téléphone portable à énergie solaire, de la télévision mobile téléphone et montre sortir de Chine avant, il est apparu nulle part ailleurs avec de nombreuses marques plus grandes même pas libérer une montre téléphone cellulaire. foakleys hijinx http://www.pascheroakleys.net/oakley-hijinx-c-33.html ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2013-04-04 09:17 Message: Unlike in the past, wearing prescription eyeglasses is no longer something to shameful of and boys DO make passes at girls who wear glasses! While you'll always be able to find cheap eyeglasses online, it's better to find a high quality pair of eye glasses than to buy something just because it's the cheaper option. Today's glasses aren't made with the same quality materials as they used to be because people aren't wearing the same pair of eyeglasses for as long as they used to. While the industry has evolved, so have the people wearing eyeglasses. foakleys http://fakeoakleysport-soaho.webs.com ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2010-07-07 18: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 11: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 08: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 12: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...> - 2013-04-04 16:17:46
|
Patches item #2035169, was opened at 2008-08-01 11:52 Message generated for change (Comment added) made by nobody 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: Nobody/Anonymous (nobody) Date: 2013-04-04 09:17 Message: Unlike in the past, wearing prescription eyeglasses is no longer something to shameful of and boys DO make passes at girls who wear glasses! While you'll always be able to find cheap eyeglasses online, it's better to find a high quality pair of eye glasses than to buy something just because it's the cheaper option. Today's glasses aren't made with the same quality materials as they used to be because people aren't wearing the same pair of eyeglasses for as long as they used to. While the industry has evolved, so have the people wearing eyeglasses. foakleys http://fakeoakleysport-soaho.webs.com ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2010-07-07 18: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 11: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 08: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 12: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...> - 2013-04-04 15:49:53
|
Patches item #3513556, was opened at 2012-03-31 03:13 Message generated for change (Comment added) made by sirkkalap You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3513556&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: Dmytro Kovalchuk (dimasmith) Assigned to: Nobody/Anonymous (nobody) Summary: Support for Java 7 diamond operator (ID: 3327154) Initial Comment: Patch for JavaParser to support Java 7 Diamond Operator (<>). ---------------------------------------------------------------------- Comment By: Petri Sirkkala (sirkkalap) Date: 2013-04-04 08:49 Message: Is there any progress related to this? What version has this issue? I am sorry to ask such simple questions like these, but unfortunately I am not familiar with SF-tracker and I can not find this informantion readily from here. ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2012-11-19 14:03 Message: Thanks for submitting this patch. Unfortunately, the JavaParser.java file that was modified is a file that is generated by the JavaNCSS code that is under the javancss directory. What is really needed is a modification to the JavaNCSS code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3513556&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2013-03-30 09:46:00
|
Patches item #1255463, was opened at 2005-08-09 21: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: 2013-03-30 02:45 Message: Hermes Bags http://hermesbags.v5s7.com de gracieux qualit - colis agile et soign ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2013-03-27 20:41 Message: I have read some just right stuff here. Certainly value bookmarking for revisiting. I wonder how so much attempt you put to create the sort of great informative website. Burberry Sale http://burberrysale118.cabanova.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-08-18 06:03 Message: Wow! I almost forgot ever working on this! ---------------------------------------------------------------------- Comment By: James Seigel (cgul) Date: 2005-09-02 06: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 07:56 Message: Logged In: YES user_id=1216999 James, will you implement it? ---------------------------------------------------------------------- Comment By: James Seigel (cgul) Date: 2005-08-11 05:35 Message: Logged In: YES user_id=1282699 Sounds good. Cheers James ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-08-10 21: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 08:22 Message: Logged In: YES user_id=1282699 Sounds good Grzegorz. Cheers James ---------------------------------------------------------------------- Comment By: Grzegorz Lukasik (hauserx) Date: 2005-08-10 08: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 07: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 07: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...> - 2013-03-28 03:41:19
|
Patches item #1255463, was opened at 2005-08-09 21: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: 2013-03-27 20:41 Message: I have read some just right stuff here. Certainly value bookmarking for revisiting. I wonder how so much attempt you put to create the sort of great informative website. Burberry Sale http://burberrysale118.cabanova.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-08-18 06:03 Message: Wow! I almost forgot ever working on this! ---------------------------------------------------------------------- Comment By: James Seigel (cgul) Date: 2005-09-02 06: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 07:56 Message: Logged In: YES user_id=1216999 James, will you implement it? ---------------------------------------------------------------------- Comment By: James Seigel (cgul) Date: 2005-08-11 05:35 Message: Logged In: YES user_id=1282699 Sounds good. Cheers James ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-08-10 21: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 08:22 Message: Logged In: YES user_id=1282699 Sounds good Grzegorz. Cheers James ---------------------------------------------------------------------- Comment By: Grzegorz Lukasik (hauserx) Date: 2005-08-10 08: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 07: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 07: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...> - 2013-02-06 18:23:47
|
Patches item #3010530, was opened at 2010-06-02 08:03 Message generated for change (Comment added) made by 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: Fabio Arezi () Date: 2013-02-06 10:23 Message: this arguments don't have in ant task yet. ---------------------------------------------------------------------- Comment By: Tad E. Smith (tcsmith) Date: 2010-07-17 09: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 15: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 14: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 18: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...> - 2012-12-18 21:18:53
|
Patches item #3431812, was opened at 2011-11-01 03:43 Message generated for change (Comment added) made by robmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3431812&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: Bas de Bakker (basdebakker) Assigned to: Nobody/Anonymous (nobody) Summary: Generate stack map frames required in Java 7 Initial Comment: In Java 6, the StackMapTable attribute was introduced. At that time it was already announced that this would become required in Java 7. This patch makes ASM regenerate those attributes from the modified byte code, avoiding VerifyErrors in the instrumented class files. ---------------------------------------------------------------------- Comment By: Rob Moore (robmoore) Date: 2012-12-18 13:18 Message: Any chance that this fix will be included in a release soon? Thanks! ---------------------------------------------------------------------- Comment By: Bas de Bakker (basdebakker) Date: 2012-11-22 01:28 Message: The asm feature to compute the stack map tables may need to load the classes. Here's a quote from page 45 of the asm 4.0 manual: "Note also that, in order to compute frames automatically, it is sometimes necessary to compute the common super class of two given classes. By default the ClassWriter class computes this, in the getCommonSuperClass method, by loading the two classes into the JVM and by using the reflection API." What I did in our project was to add the uninstrumented class files to the classpath of the coberture-instrument task in the ant taskdef call. ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2012-11-21 07:58 Message: Thanks for the patch. Is there anything else required or left out of the patch? The net.sourceforge.cobertura.test.FunctionalTest.simpleFunctionalTest() fails when this patch is applied. Is a later version of ASM needed? Here is the error: [cobertura-instrument] Cobertura null - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [cobertura-instrument] Instrumenting 2 files to C:\Users\jwlewi\AppData\Local\Temp\cobertura_test1353512654190\instrument [cobertura-instrument] DEBUG - Instrumenting class C:\Users\jwlewi\AppData\Local\Temp\cobertura_test1353512654190\src\mypackage\Main.class [cobertura-instrument] WARN - Unable to instrument file C:\Users\jwlewi\AppData\Local\Temp\cobertura_test1353512654190\src\mypackage\Main.class [cobertura-instrument] java.lang.RuntimeException: java.lang.ClassNotFoundException: mypackage.Simple [cobertura-instrument] Exception in thread "main" java.lang.RuntimeException: java.lang.ClassNotFoundException: mypackage.Simple [cobertura-instrument] at org.objectweb.asm.ClassWriter.getCommonSuperClass(Unknown Source) [cobertura-instrument] at org.objectweb.asm.ClassWriter.getCommonSuperClass(Unknown Source) [cobertura-instrument] at org.objectweb.asm.ClassWriter.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.ClassWriter.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.Frame.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.Frame.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.Frame.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.Frame.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.MethodWriter.visitMaxs(Unknown Source) [cobertura-instrument] at org.objectweb.asm.MethodWriter.visitMaxs(Unknown Source) [cobertura-instrument] at org.objectweb.asm.MethodAdapter.visitMaxs(Unknown Source) [cobertura-instrument] at org.objectweb.asm.MethodAdapter.visitMaxs(Unknown Source) [cobertura-instrument] at net.sourceforge.cobertura.instrument.SecondPassMethodInstrumenter.visitMaxs(SecondPassMethodInstrumenter.java:353) [cobertura-instrument] at org.objectweb.asm.tree.MethodNode.accept(Unknown Source) [cobertura-instrument] at net.sourceforge.cobertura.instrument.FirstPassMethodInstrumenter.visitEnd(FirstPassMethodInstrumenter.java:171) [cobertura-instrument] at org.objectweb.asm.ClassReader.accept(Unknown Source) [cobertura-instrument] at org.objectweb.asm.ClassReader.accept(Unknown Source) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.addInstrumentationToSingleClass(Main.java:367) [cobertura-instrument] at net.sourceforge.cobertura.instrument.SecondPassMethodInstrumenter.visitMaxs(SecondPassMethodInstrumenter.java:353) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.addInstrumentation(Main.java:425) [cobertura-instrument] at org.objectweb.asm.tree.MethodNode.accept(Unknown Source) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.parseArguments(Main.java:511) [cobertura-instrument] at net.sourceforge.cobertura.instrument.FirstPassMethodInstrumenter.visitEnd(FirstPassMethodInstrumenter.java:171) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.main(Main.java:533) [cobertura-instrument] at org.objectweb.asm.ClassReader.accept(Unknown Source) [cobertura-instrument] Caused by: java.lang.ClassNotFoundException: mypackage.Simple [cobertura-instrument] at java.net.URLClassLoader$1.run(URLClassLoader.java:200) [cobertura-instrument] at org.objectweb.asm.ClassReader.accept(Unknown Source) [cobertura-instrument] at java.security.AccessController.doPrivileged(Native Method) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.addInstrumentationToSingleClass(Main.java:367) [cobertura-instrument] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.addInstrumentation(Main.java:425) [cobertura-instrument] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.parseArguments(Main.java:511) [cobertura-instrument] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.main(Main.java:533) [cobertura-instrument] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [cobertura-instrument] Caused by: java.lang.ClassNotFoundException: mypackage.Simple [cobertura-instrument] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [cobertura-instrument] at java.net.URLClassLoader$1.run(URLClassLoader.java:200) [cobertura-instrument] at java.lang.Class.forName0(Native Method) [cobertura-instrument] at java.security.AccessController.doPrivileged(Native Method) [cobertura-instrument] at java.lang.Class.forName(Class.java:164) [cobertura-instrument] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [cobertura-instrument] ... 15 more [cobertura-instrument] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [cobertura-instrument] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [cobertura-instrument] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [cobertura-instrument] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [cobertura-instrument] at java.lang.Class.forName0(Native Method) [cobertura-instrument] at java.lang.Class.forName(Class.java:164) [cobertura-instrument] ... 15 more ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3431812&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2012-11-28 22:01:50
|
Patches item #3577330, was opened at 2012-10-15 07:29 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3577330&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: Matthieu Moy (matthieu_moy) Assigned to: Nobody/Anonymous (nobody) Summary: Allow the user to chose the verbosity at runtime Initial Comment: By default, cobertura-instrumented programs output 4 lines of informative messages. In some testsuites, these lines can make the tests fail. Allow the user to disable them by setting an environment variable before running the testsuite. We introduce a minimalistic trace system that reads the environment variable. Currently, the trace level is indeed a yes/no configuration, but we leave room for future finer-grained control with the same environment variable. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-11-28 14:01 Message: Hello, i think that i saw you visited my weblog so i came to return the favor.I am trying to find things to improve my web site!I suppose its ok to use some of your ideas!! <a href="http://www.everydayhealth.com/profile/salt8seal" title="Gorgeous">Gorgeous</a> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3577330&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2012-11-22 09:28:25
|
Patches item #3431812, was opened at 2011-11-01 03:43 Message generated for change (Comment added) made by basdebakker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3431812&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: Bas de Bakker (basdebakker) Assigned to: Nobody/Anonymous (nobody) Summary: Generate stack map frames required in Java 7 Initial Comment: In Java 6, the StackMapTable attribute was introduced. At that time it was already announced that this would become required in Java 7. This patch makes ASM regenerate those attributes from the modified byte code, avoiding VerifyErrors in the instrumented class files. ---------------------------------------------------------------------- >Comment By: Bas de Bakker (basdebakker) Date: 2012-11-22 01:28 Message: The asm feature to compute the stack map tables may need to load the classes. Here's a quote from page 45 of the asm 4.0 manual: "Note also that, in order to compute frames automatically, it is sometimes necessary to compute the common super class of two given classes. By default the ClassWriter class computes this, in the getCommonSuperClass method, by loading the two classes into the JVM and by using the reflection API." What I did in our project was to add the uninstrumented class files to the classpath of the coberture-instrument task in the ant taskdef call. ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2012-11-21 07:58 Message: Thanks for the patch. Is there anything else required or left out of the patch? The net.sourceforge.cobertura.test.FunctionalTest.simpleFunctionalTest() fails when this patch is applied. Is a later version of ASM needed? Here is the error: [cobertura-instrument] Cobertura null - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [cobertura-instrument] Instrumenting 2 files to C:\Users\jwlewi\AppData\Local\Temp\cobertura_test1353512654190\instrument [cobertura-instrument] DEBUG - Instrumenting class C:\Users\jwlewi\AppData\Local\Temp\cobertura_test1353512654190\src\mypackage\Main.class [cobertura-instrument] WARN - Unable to instrument file C:\Users\jwlewi\AppData\Local\Temp\cobertura_test1353512654190\src\mypackage\Main.class [cobertura-instrument] java.lang.RuntimeException: java.lang.ClassNotFoundException: mypackage.Simple [cobertura-instrument] Exception in thread "main" java.lang.RuntimeException: java.lang.ClassNotFoundException: mypackage.Simple [cobertura-instrument] at org.objectweb.asm.ClassWriter.getCommonSuperClass(Unknown Source) [cobertura-instrument] at org.objectweb.asm.ClassWriter.getCommonSuperClass(Unknown Source) [cobertura-instrument] at org.objectweb.asm.ClassWriter.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.ClassWriter.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.Frame.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.Frame.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.Frame.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.Frame.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.MethodWriter.visitMaxs(Unknown Source) [cobertura-instrument] at org.objectweb.asm.MethodWriter.visitMaxs(Unknown Source) [cobertura-instrument] at org.objectweb.asm.MethodAdapter.visitMaxs(Unknown Source) [cobertura-instrument] at org.objectweb.asm.MethodAdapter.visitMaxs(Unknown Source) [cobertura-instrument] at net.sourceforge.cobertura.instrument.SecondPassMethodInstrumenter.visitMaxs(SecondPassMethodInstrumenter.java:353) [cobertura-instrument] at org.objectweb.asm.tree.MethodNode.accept(Unknown Source) [cobertura-instrument] at net.sourceforge.cobertura.instrument.FirstPassMethodInstrumenter.visitEnd(FirstPassMethodInstrumenter.java:171) [cobertura-instrument] at org.objectweb.asm.ClassReader.accept(Unknown Source) [cobertura-instrument] at org.objectweb.asm.ClassReader.accept(Unknown Source) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.addInstrumentationToSingleClass(Main.java:367) [cobertura-instrument] at net.sourceforge.cobertura.instrument.SecondPassMethodInstrumenter.visitMaxs(SecondPassMethodInstrumenter.java:353) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.addInstrumentation(Main.java:425) [cobertura-instrument] at org.objectweb.asm.tree.MethodNode.accept(Unknown Source) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.parseArguments(Main.java:511) [cobertura-instrument] at net.sourceforge.cobertura.instrument.FirstPassMethodInstrumenter.visitEnd(FirstPassMethodInstrumenter.java:171) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.main(Main.java:533) [cobertura-instrument] at org.objectweb.asm.ClassReader.accept(Unknown Source) [cobertura-instrument] Caused by: java.lang.ClassNotFoundException: mypackage.Simple [cobertura-instrument] at java.net.URLClassLoader$1.run(URLClassLoader.java:200) [cobertura-instrument] at org.objectweb.asm.ClassReader.accept(Unknown Source) [cobertura-instrument] at java.security.AccessController.doPrivileged(Native Method) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.addInstrumentationToSingleClass(Main.java:367) [cobertura-instrument] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.addInstrumentation(Main.java:425) [cobertura-instrument] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.parseArguments(Main.java:511) [cobertura-instrument] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.main(Main.java:533) [cobertura-instrument] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [cobertura-instrument] Caused by: java.lang.ClassNotFoundException: mypackage.Simple [cobertura-instrument] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [cobertura-instrument] at java.net.URLClassLoader$1.run(URLClassLoader.java:200) [cobertura-instrument] at java.lang.Class.forName0(Native Method) [cobertura-instrument] at java.security.AccessController.doPrivileged(Native Method) [cobertura-instrument] at java.lang.Class.forName(Class.java:164) [cobertura-instrument] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [cobertura-instrument] ... 15 more [cobertura-instrument] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [cobertura-instrument] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [cobertura-instrument] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [cobertura-instrument] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [cobertura-instrument] at java.lang.Class.forName0(Native Method) [cobertura-instrument] at java.lang.Class.forName(Class.java:164) [cobertura-instrument] ... 15 more ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3431812&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2012-11-21 15:58:58
|
Patches item #3431812, was opened at 2011-11-01 03:43 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3431812&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: Bas de Bakker (basdebakker) Assigned to: Nobody/Anonymous (nobody) Summary: Generate stack map frames required in Java 7 Initial Comment: In Java 6, the StackMapTable attribute was introduced. At that time it was already announced that this would become required in Java 7. This patch makes ASM regenerate those attributes from the modified byte code, avoiding VerifyErrors in the instrumented class files. ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2012-11-21 07:58 Message: Thanks for the patch. Is there anything else required or left out of the patch? The net.sourceforge.cobertura.test.FunctionalTest.simpleFunctionalTest() fails when this patch is applied. Is a later version of ASM needed? Here is the error: [cobertura-instrument] Cobertura null - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [cobertura-instrument] Instrumenting 2 files to C:\Users\jwlewi\AppData\Local\Temp\cobertura_test1353512654190\instrument [cobertura-instrument] DEBUG - Instrumenting class C:\Users\jwlewi\AppData\Local\Temp\cobertura_test1353512654190\src\mypackage\Main.class [cobertura-instrument] WARN - Unable to instrument file C:\Users\jwlewi\AppData\Local\Temp\cobertura_test1353512654190\src\mypackage\Main.class [cobertura-instrument] java.lang.RuntimeException: java.lang.ClassNotFoundException: mypackage.Simple [cobertura-instrument] Exception in thread "main" java.lang.RuntimeException: java.lang.ClassNotFoundException: mypackage.Simple [cobertura-instrument] at org.objectweb.asm.ClassWriter.getCommonSuperClass(Unknown Source) [cobertura-instrument] at org.objectweb.asm.ClassWriter.getCommonSuperClass(Unknown Source) [cobertura-instrument] at org.objectweb.asm.ClassWriter.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.ClassWriter.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.Frame.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.Frame.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.Frame.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.Frame.a(Unknown Source) [cobertura-instrument] at org.objectweb.asm.MethodWriter.visitMaxs(Unknown Source) [cobertura-instrument] at org.objectweb.asm.MethodWriter.visitMaxs(Unknown Source) [cobertura-instrument] at org.objectweb.asm.MethodAdapter.visitMaxs(Unknown Source) [cobertura-instrument] at org.objectweb.asm.MethodAdapter.visitMaxs(Unknown Source) [cobertura-instrument] at net.sourceforge.cobertura.instrument.SecondPassMethodInstrumenter.visitMaxs(SecondPassMethodInstrumenter.java:353) [cobertura-instrument] at org.objectweb.asm.tree.MethodNode.accept(Unknown Source) [cobertura-instrument] at net.sourceforge.cobertura.instrument.FirstPassMethodInstrumenter.visitEnd(FirstPassMethodInstrumenter.java:171) [cobertura-instrument] at org.objectweb.asm.ClassReader.accept(Unknown Source) [cobertura-instrument] at org.objectweb.asm.ClassReader.accept(Unknown Source) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.addInstrumentationToSingleClass(Main.java:367) [cobertura-instrument] at net.sourceforge.cobertura.instrument.SecondPassMethodInstrumenter.visitMaxs(SecondPassMethodInstrumenter.java:353) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.addInstrumentation(Main.java:425) [cobertura-instrument] at org.objectweb.asm.tree.MethodNode.accept(Unknown Source) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.parseArguments(Main.java:511) [cobertura-instrument] at net.sourceforge.cobertura.instrument.FirstPassMethodInstrumenter.visitEnd(FirstPassMethodInstrumenter.java:171) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.main(Main.java:533) [cobertura-instrument] at org.objectweb.asm.ClassReader.accept(Unknown Source) [cobertura-instrument] Caused by: java.lang.ClassNotFoundException: mypackage.Simple [cobertura-instrument] at java.net.URLClassLoader$1.run(URLClassLoader.java:200) [cobertura-instrument] at org.objectweb.asm.ClassReader.accept(Unknown Source) [cobertura-instrument] at java.security.AccessController.doPrivileged(Native Method) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.addInstrumentationToSingleClass(Main.java:367) [cobertura-instrument] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.addInstrumentation(Main.java:425) [cobertura-instrument] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.parseArguments(Main.java:511) [cobertura-instrument] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [cobertura-instrument] at net.sourceforge.cobertura.instrument.Main.main(Main.java:533) [cobertura-instrument] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [cobertura-instrument] Caused by: java.lang.ClassNotFoundException: mypackage.Simple [cobertura-instrument] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [cobertura-instrument] at java.net.URLClassLoader$1.run(URLClassLoader.java:200) [cobertura-instrument] at java.lang.Class.forName0(Native Method) [cobertura-instrument] at java.security.AccessController.doPrivileged(Native Method) [cobertura-instrument] at java.lang.Class.forName(Class.java:164) [cobertura-instrument] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [cobertura-instrument] ... 15 more [cobertura-instrument] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [cobertura-instrument] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [cobertura-instrument] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [cobertura-instrument] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [cobertura-instrument] at java.lang.Class.forName0(Native Method) [cobertura-instrument] at java.lang.Class.forName(Class.java:164) [cobertura-instrument] ... 15 more ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3431812&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2012-11-19 22:03:56
|
Patches item #3513556, was opened at 2012-03-31 03:13 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3513556&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: Dmytro Kovalchuk (dimasmith) Assigned to: Nobody/Anonymous (nobody) Summary: Support for Java 7 diamond operator (ID: 3327154) Initial Comment: Patch for JavaParser to support Java 7 Diamond Operator (<>). ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2012-11-19 14:03 Message: Thanks for submitting this patch. Unfortunately, the JavaParser.java file that was modified is a file that is generated by the JavaNCSS code that is under the javancss directory. What is really needed is a modification to the JavaNCSS code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3513556&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2012-11-16 04:39:36
|
Patches item #2792112, was opened at 2009-05-15 01:48 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2792112&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: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: John Lewis (lewijw) Summary: Cobertura fails with JUnit tests that uses multiple threads Initial Comment: A JUnit test with a number of threads which makes calls to the same class (not necessaries the same object) will fail with Cobertura because of a bug in Cobertura. The problem is that the classes inside Cobertura's coveragedata package is not thread safe and when collecting data from concurrent threads this can result in an exception which look something like: java.lang.IndexOutOfBoundsException: Index: 0, Size: 1 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at net.sourceforge.cobertura.coveragedata.LineData.getJumpData(LineData.java:316) at net.sourceforge.cobertura.coveragedata.LineData.touchJump(LineData.java:259) at net.sourceforge.cobertura.coveragedata.ClassData.touchJump(ClassData.java:453) at code.ConcurrentAccessObject.addText(ConcurrentAccessObject.java:25) at test.ConcurrentAccessObjectTest$TestThread.run(ConcurrentAccessObjectTest.java:30) I have written a fix for the bug which makes the touch methods on the ClassData class synchronized. This does that only one thread is allowed to update the coveragedata when running tests. Please note that the bug is not easy to reproduce consistently because it is a concurrency bug. The included JUnit test case will therefore not always work. Also note that is fixes the same problem as Cobertura patch 2722288 in SourceForge. But I think that my patch may be a simpler and better solution. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-11-15 20:39 Message: I was curious if you ever thought of changing the structure of your blog? Its very well written; I love what youve got to say. But maybe you could a little more in the way of content so people could connect with it better. Youve got an awful lot of text for only having 1 or two images. Maybe you could space it out better? north face osito jacket http://sfwgdqdfge.blinkweb.com/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-11-10 23:36 Message: Greetings from California! I'm bored to death at work so I decided to browse your website on my iphone during lunch break. I enjoy the information you present here and can't wait to take a look when I get home. I'm amazed at how fast your blog loaded on my cell phone .. I'm not even using WIFI, just 3G .. Anyways, great blog! north face jackets clearance http://yuywfrbgzf.blogoak.com/ ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2009-06-25 03:55 Message: Thanks for the patch, but I cannot open it for some reason. Is it corrupt? This issue has recently been fixed. I hope to release 1.9.2 today. It will have the fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2792112&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2012-11-11 07:36:48
|
Patches item #2792112, was opened at 2009-05-15 01:48 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2792112&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: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: John Lewis (lewijw) Summary: Cobertura fails with JUnit tests that uses multiple threads Initial Comment: A JUnit test with a number of threads which makes calls to the same class (not necessaries the same object) will fail with Cobertura because of a bug in Cobertura. The problem is that the classes inside Cobertura's coveragedata package is not thread safe and when collecting data from concurrent threads this can result in an exception which look something like: java.lang.IndexOutOfBoundsException: Index: 0, Size: 1 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at net.sourceforge.cobertura.coveragedata.LineData.getJumpData(LineData.java:316) at net.sourceforge.cobertura.coveragedata.LineData.touchJump(LineData.java:259) at net.sourceforge.cobertura.coveragedata.ClassData.touchJump(ClassData.java:453) at code.ConcurrentAccessObject.addText(ConcurrentAccessObject.java:25) at test.ConcurrentAccessObjectTest$TestThread.run(ConcurrentAccessObjectTest.java:30) I have written a fix for the bug which makes the touch methods on the ClassData class synchronized. This does that only one thread is allowed to update the coveragedata when running tests. Please note that the bug is not easy to reproduce consistently because it is a concurrency bug. The included JUnit test case will therefore not always work. Also note that is fixes the same problem as Cobertura patch 2722288 in SourceForge. But I think that my patch may be a simpler and better solution. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-11-10 23:36 Message: Greetings from California! I'm bored to death at work so I decided to browse your website on my iphone during lunch break. I enjoy the information you present here and can't wait to take a look when I get home. I'm amazed at how fast your blog loaded on my cell phone .. I'm not even using WIFI, just 3G .. Anyways, great blog! north face jackets clearance http://yuywfrbgzf.blogoak.com/ ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2009-06-25 03:55 Message: Thanks for the patch, but I cannot open it for some reason. Is it corrupt? This issue has recently been fixed. I hope to release 1.9.2 today. It will have the fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2792112&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2012-10-15 14:29:02
|
Patches item #3577330, was opened at 2012-10-15 07:29 Message generated for change (Tracker Item Submitted) made by matthieu_moy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3577330&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: Matthieu Moy (matthieu_moy) Assigned to: Nobody/Anonymous (nobody) Summary: Allow the user to chose the verbosity at runtime Initial Comment: By default, cobertura-instrumented programs output 4 lines of informative messages. In some testsuites, these lines can make the tests fail. Allow the user to disable them by setting an environment variable before running the testsuite. We introduce a minimalistic trace system that reads the environment variable. Currently, the trace level is indeed a yes/no configuration, but we leave room for future finer-grained control with the same environment variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3577330&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2012-08-18 13:03:40
|
Patches item #1255463, was opened at 2005-08-09 21: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: 2012-08-18 06:03 Message: Wow! I almost forgot ever working on this! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-08-18 00:14 Message: EwAMDa <a href="http://yvynttjcltwx.com/">yvynttjcltwx</a>, [url=http://ibichrnxemja.com/]ibichrnxemja[/url], [link=http://vpnrspjqlcle.com/]vpnrspjqlcle[/link], http://idswxlwolgfu.com/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-08-20 19: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 06: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 07:56 Message: Logged In: YES user_id=1216999 James, will you implement it? ---------------------------------------------------------------------- Comment By: James Seigel (cgul) Date: 2005-08-11 05:35 Message: Logged In: YES user_id=1282699 Sounds good. Cheers James ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-08-10 21: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 08:22 Message: Logged In: YES user_id=1282699 Sounds good Grzegorz. Cheers James ---------------------------------------------------------------------- Comment By: Grzegorz Lukasik (hauserx) Date: 2005-08-10 08: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 07: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 07: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...> - 2012-08-18 07:14:05
|
Patches item #1255463, was opened at 2005-08-09 21: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: 2012-08-18 00:14 Message: EwAMDa <a href="http://yvynttjcltwx.com/">yvynttjcltwx</a>, [url=http://ibichrnxemja.com/]ibichrnxemja[/url], [link=http://vpnrspjqlcle.com/]vpnrspjqlcle[/link], http://idswxlwolgfu.com/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-08-20 19: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 06: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 07:56 Message: Logged In: YES user_id=1216999 James, will you implement it? ---------------------------------------------------------------------- Comment By: James Seigel (cgul) Date: 2005-08-11 05:35 Message: Logged In: YES user_id=1282699 Sounds good. Cheers James ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-08-10 21: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 08:22 Message: Logged In: YES user_id=1282699 Sounds good Grzegorz. Cheers James ---------------------------------------------------------------------- Comment By: Grzegorz Lukasik (hauserx) Date: 2005-08-10 08: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 07: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 07: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...> - 2012-03-31 10:13:24
|
Patches item #3513556, was opened at 2012-03-31 03:13 Message generated for change (Tracker Item Submitted) made by dimasmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3513556&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: Dmytro Kovalchuk (dimasmith) Assigned to: Nobody/Anonymous (nobody) Summary: Support for Java 7 diamond operator (ID: 3327154) Initial Comment: Patch for JavaParser to support Java 7 Diamond Operator (<>). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3513556&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2012-02-20 11:53:33
|
Patches item #1670810, was opened at 2007-02-28 04:58 Message generated for change (Comment added) made by kutterma You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1670810&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: Nobody/Anonymous (nobody) Summary: support multibyte chracter Initial Comment: Hi, cobertura does not support multibyte character. This is problem for all of non English people. We can not see the report correctly if java source code have multibyte charancter. Please take attached patch. regards, Takashi Okamoto ---------------------------------------------------------------------- Comment By: Martin Kutter (kutterma) Date: 2012-02-20 03:53 Message: IMHO the patch attached to https://sourceforge.net/tracker/index.php?func=detail&aid=2907314&group_id=130558&atid=720015 (Bug 2907314) is clearer (and in contrast to the one attached, it's not garbled by inconsistent line endings). I'll attach it, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1670810&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2011-12-06 16:12:21
|
Patches item #3138755, was opened at 2010-12-16 12:45 Message generated for change (Comment added) made by nobody 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 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-12-06 08:12 Message: 8BH75l <a href="http://suafmlszgqcf.com/">suafmlszgqcf</a>, [url=http://vztpxsdwxobr.com/]vztpxsdwxobr[/url], [link=http://twltkpqkziij.com/]twltkpqkziij[/link], http://eadmlaqeyyim.com/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3138755&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2011-11-01 10:43:51
|
Patches item #3431812, was opened at 2011-11-01 11:43 Message generated for change (Tracker Item Submitted) made by basdebakker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3431812&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: Bas de Bakker (basdebakker) Assigned to: Nobody/Anonymous (nobody) Summary: Generate stack map frames required in Java 7 Initial Comment: In Java 6, the StackMapTable attribute was introduced. At that time it was already announced that this would become required in Java 7. This patch makes ASM regenerate those attributes from the modified byte code, avoiding VerifyErrors in the instrumented class files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3431812&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2011-05-20 09:26:15
|
Patches item #3304996, was opened at 2011-05-20 12:26 Message generated for change (Tracker Item Submitted) made by jouni You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3304996&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: Jouni K Seppnen (jouni) Assigned to: Nobody/Anonymous (nobody) Summary: Don't try to color non-Java code by syntax Initial Comment: (This addresses partially the same problem as #3304991 in a different way, but IMHO both are worth applying.) Since Cobertura is implemented via instrumenting class files, it is to some degree usable for JVM languages other than Java. However, applying Java code colorization to non-Java code will result in nonsensical output. It is better to view e.g. Clojure source without any colorization than with mistaken colorization. This patch looks at the filename of the source file, and if it does not end in .java, does not attempt to apply colorization. The copyright to this patch belongs to my employer, ZenRobotics Ltd., and I have received permission to submit the patch to Cobertura. The patch is against Subversion branch v1_9_4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3304996&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2011-05-20 09:21:00
|
Patches item #3304991, was opened at 2011-05-20 12:19 Message generated for change (Comment added) made by jouni You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3304991&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: Jouni K Seppnen (jouni) Assigned to: Nobody/Anonymous (nobody) Summary: Fix crash in case of escaped double-quote at line beginning Initial Comment: Since Cobertura is implemented via instrumenting class files, it is to some degree usable for JVM languages other than Java. When running Cobertura against a project written in Clojure, I had a crash because the code-colorizing parser tried to access a character before the beginning of a line in a multi-line string. This does not happen in syntactically correct Java, but IMHO crashing on unexpected input should be fixed. The patch adds a test case for the problem and changes the logic to prevent the crash. The copyright to this patch belongs to my employer, ZenRobotics Ltd., and I have received permission to submit the patch to Cobertura. ---------------------------------------------------------------------- >Comment By: Jouni K Seppnen (jouni) Date: 2011-05-20 12:20 Message: Note: the patch is against the Subversion branch v1_9_4, as that is the newest release but the released source archive does not have all files needed for compilation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3304991&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2011-05-20 09:19:16
|
Patches item #3304991, was opened at 2011-05-20 12:19 Message generated for change (Tracker Item Submitted) made by jouni You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3304991&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: Jouni K Seppnen (jouni) Assigned to: Nobody/Anonymous (nobody) Summary: Fix crash in case of escaped double-quote at line beginning Initial Comment: Since Cobertura is implemented via instrumenting class files, it is to some degree usable for JVM languages other than Java. When running Cobertura against a project written in Clojure, I had a crash because the code-colorizing parser tried to access a character before the beginning of a line in a multi-line string. This does not happen in syntactically correct Java, but IMHO crashing on unexpected input should be fixed. The patch adds a test case for the problem and changes the logic to prevent the crash. The copyright to this patch belongs to my employer, ZenRobotics Ltd., and I have received permission to submit the patch to Cobertura. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3304991&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2011-05-19 11:57:43
|
Patches item #2806475, was opened at 2009-06-15 14:38 Message generated for change (Comment added) made by pranav24061980 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&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: Chris van Es (cvanes) Assigned to: John Lewis (lewijw) Summary: FileLocker exception when writing coverage data Initial Comment: With the latest java 6 there's now an exception thrown when you attempt to register a shutdown hook whilst the jvm is shutting down, previously the call would just have been ignored. This means that as a jvm is being shutdown there is an attempt by cobertura to register the hook to delete a lock on the coverage file and an exception thrown before coverage data had been written. I've patched this to use a try/catch/finally block to delete the lock instead of the java.io.File.deleteOnExit method ---------------------------------------------------------------------- Comment By: Pranav (pranav24061980) Date: 2011-05-19 17:27 Message: But how can we compile these two java files.. after making changes I am not able to compile this file getting compilation errors.. compilar is not able to find any class file. ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2009-06-25 20:25 Message: Turns out that the delete of the lock file cannot be done while the lock is in place. So, since the FileLocker.release() method deletes the file anyway, I'm removing the FileLocker.delete method. ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2009-06-25 19:49 Message: Rick, I see your point. I forgot the release method is doing a delete. I've removed the delete method, and within release(), I have moved the delete of the file before the release of the lock. John ---------------------------------------------------------------------- Comment By: Rick Riemer (ricq) Date: 2009-06-25 18:24 Message: The patch seems to do the job. It seems strange to add the delete call to ProjectData though, because release() already does a delete(). Two consecutive deletes won't make the file go more away. Looking forward to the release. ---------------------------------------------------------------------- Comment By: Chris van Es (cvanes) Date: 2009-06-25 17:27 Message: Yes, it does seem better to catch Throwable, although I think you're right that current behaviour should remain, it's an error that we can't really recover from. ---------------------------------------------------------------------- Comment By: John Lewis (lewijw) Date: 2009-06-25 16:17 Message: Thanks for the patch Chris! I applied your patch pretty much the way you submitted it with the following changes: 1. I delete the file before releasing the lock. Let me know if you see a problem with this. 2. I removed the catch (Exception). I hope to release 1.9.2 today, and I am more comfortable with keeping the current behavior when an Exception is thrown. We can add the print of the stack trace later if that is better, but if we do, isn't it better to catch (Throwable) instead of just Exception? Revision 604. Thanks again! John ---------------------------------------------------------------------- Comment By: Chris van Es (cvanes) Date: 2009-06-16 14:07 Message: Ok, I've updated the ProjectData class to print out some info if an exception is thrown whilst attempting to output coverage data. I haven't verified but this issue may only affect java 6_14 at the minute, I haven't had a chance to determine if this is an issue with earlier updates. ---------------------------------------------------------------------- Comment By: wyvern5 (wyvern5) Date: 2009-06-16 06:03 Message: I cast a vote in favor of prioritizing this fix. :) Are you sure that the empty catch block is appropriate, though? It'd mean errors when merging and saving coverage data would be silently ignored, if I'm understanding that snippet correctly. (I haven't looked into what the calls inside the try {} are doing, though -- I'm just guessing based on the method names.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2011-04-20 19:26:50
|
Patches item #3290509, was opened at 2011-04-20 20:26 Message generated for change (Tracker Item Submitted) made by yetanothermatt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3290509&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: Matthew Smith (yetanothermatt) Assigned to: Nobody/Anonymous (nobody) Summary: Add sortable complexity & coverage to frame-sourcefiles.html Initial Comment: Patch for feature request 3290498. This patch to HtmlReport.java replaces the list of classes in frame-sourcefiles.html with a sortable table (the same information as in frame-summary but in a more concise format). It incidentally adds a title element to those table headers that have a link to the help file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720017&aid=3290509&group_id=130558 |
1 message has been excluded from this view by a project administrator.