cobertura-patches — Automated emails from our patch tracking system

[ cobertura-Patches-1815311 ] Ignore private constructor

[SourceForge.net <no...@so...>]

Patches item #1815311, was opened at 2007-10-17 21:44
Message generated for change (Comment added) made by rsinnema
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1815311&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: Remon Sinnema (rsinnema)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ignore private constructor

Initial Comment:
See http://sourceforge.net/tracker/index.php?func=detail&aid=1753833&group_id=130558&atid=720015

----------------------------------------------------------------------

>Comment By: Remon Sinnema (rsinnema)
Date: 2007-10-23 23:34

Message:
Logged In: YES 
user_id=451078
Originator: YES

Private constructors for utility classes are only written to suppress
generation of a default constructor. They cannot be called, and therefore
should not be instrumented.

This new version of the patch now checks whether the class really is a
utility class, i.e. if it has only static methods. If it is a utility
class, the private constructor is not instrumented, otherwise it is.

File Added: private-constructor.patch

----------------------------------------------------------------------

Comment By: Jiri Mares (jirimares)
Date: 2007-10-22 20:41

Message:
Logged In: YES 
user_id=819956
Originator: NO

We are going to aply this patch into the cobertura sources, because it is
not common behaviour to ignore private constructors. We are planning to
improve the options of selecting code to ignore ...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1815311&group_id=130558

[ cobertura-Patches-1815311 ] Ignore private constructor

[SourceForge.net <no...@so...>]

Patches item #1815311, was opened at 2007-10-17 21:44
Message generated for change (Comment added) made by jirimares
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1815311&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: None
Priority: 5
Private: No
Submitted By: Remon Sinnema (rsinnema)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ignore private constructor

Initial Comment:
See http://sourceforge.net/tracker/index.php?func=detail&aid=1753833&group_id=130558&atid=720015

----------------------------------------------------------------------

>Comment By: Jiri Mares (jirimares)
Date: 2007-10-22 20:41

Message:
Logged In: YES 
user_id=819956
Originator: NO

We are going to aply this patch into the cobertura sources, because it is
not common behaviour to ignore private constructors. We are planning to
improve the options of selecting code to ignore ...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1815311&group_id=130558

[ cobertura-Patches-1815311 ] Ignore private constructor

[SourceForge.net <no...@so...>]

Patches item #1815311, was opened at 2007-10-17 21:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1815311&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: Remon Sinnema (rsinnema)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ignore private constructor

Initial Comment:
See http://sourceforge.net/tracker/index.php?func=detail&aid=1753833&group_id=130558&atid=720015

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1815311&group_id=130558

[ cobertura-Patches-1670817 ] support encoding for multibyte character

[SourceForge.net <no...@so...>]

Patches item #1670817, was opened at 2007-02-28 14:15
Message generated for change (Settings changed) made by jirimares
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1670817&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: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: support encoding for multibyte character

Initial Comment:
Hi,

Previous patch is for 1.8. This patch is rewrite for SVN snapshot.

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 character.

Please take attached patch.

regards,

Takashi Okamoto

----------------------------------------------------------------------

Comment By: Jiri Mares (jirimares)
Date: 2007-10-08 23:20

Message:
Logged In: YES 
user_id=819956
Originator: NO

I have applied the patch, but with small change ... the default encoding
is not the System.getProperty("file.encoding") but "UTF-8" to stay
compatible. If you would like other encoding than UTF-8 you have to use the
--encoding parameter to report generation. We have to implement specifying
it also using the ANT tasks.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-10-08 10:07

Message:
Logged In: NO 

I need this patch. Window's default encoding is Windows-31J in Japan and
java sources are written by Windows-31J in general.
javac, java, ant , maven and other tools support configurable encoding.
Emma another coverage tool also suport encoding option.

IMO, support only utf-8 is lazy implementation.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-03-03 12:42

Message:
Logged In: NO 

> I guess the case you're trying to fix is where the
> Java source files are saved in an encoding other than UTF-8, but the
> Cobertura report is generated as UTF-8, so the source code 
> embedded in the
> report shows up as gibberish?

Yes. 

> Is the line "private String encoding =
> System.getProperty("file.encoding");" at the top of
> HTMLReport.java needed?
> Or is that left over from an earlier version of your changes?

No. It is my mistake. I found another mistake. encoding field in Main.java
should:

 private String encoding = System.getProperty("file.encoding");

> And for my own curiosity... is there any reason you're not using UTF-8?

We use platform default encoding in general. For example, Japanese 
MS Windows default encoding is Windows-31J and it is also default encoding
in eclipse. Most of Japanese programmer use default encoding. It is the
reason why we use other than utf-8 encoding.

regards,

Takashi Okamoto

----------------------------------------------------------------------

Comment By: Mark Doliner (thekingant)
Date: 2007-02-28 18:12

Message:
Logged In: YES 
user_id=20979
Originator: NO

Interesting patch... I guess the case you're trying to fix is where the
Java source files are saved in an encoding other than UTF-8, but the
Cobertura report is generated as UTF-8, so the source code embedded in the
report shows up as gibberish?

Is the line "private String encoding =
System.getProperty("file.encoding");" at the top of HTMLReport.java needed?
 Or is that left over from an earlier version of your changes?

And for my own curiosity... is there any reason you're not using UTF-8?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1670817&group_id=130558

[ cobertura-Patches-1670817 ] support encoding for multibyte character

[SourceForge.net <no...@so...>]

Patches item #1670817, was opened at 2007-02-28 14:15
Message generated for change (Comment added) made by jirimares
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1670817&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 encoding for multibyte character

Initial Comment:
Hi,

Previous patch is for 1.8. This patch is rewrite for SVN snapshot.

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 character.

Please take attached patch.

regards,

Takashi Okamoto

----------------------------------------------------------------------

>Comment By: Jiri Mares (jirimares)
Date: 2007-10-08 23:20

Message:
Logged In: YES 
user_id=819956
Originator: NO

I have applied the patch, but with small change ... the default encoding
is not the System.getProperty("file.encoding") but "UTF-8" to stay
compatible. If you would like other encoding than UTF-8 you have to use the
--encoding parameter to report generation. We have to implement specifying
it also using the ANT tasks.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-10-08 10:07

Message:
Logged In: NO 

I need this patch. Window's default encoding is Windows-31J in Japan and
java sources are written by Windows-31J in general.
javac, java, ant , maven and other tools support configurable encoding.
Emma another coverage tool also suport encoding option.

IMO, support only utf-8 is lazy implementation.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-03-03 12:42

Message:
Logged In: NO 

> I guess the case you're trying to fix is where the
> Java source files are saved in an encoding other than UTF-8, but the
> Cobertura report is generated as UTF-8, so the source code 
> embedded in the
> report shows up as gibberish?

Yes. 

> Is the line "private String encoding =
> System.getProperty("file.encoding");" at the top of
> HTMLReport.java needed?
> Or is that left over from an earlier version of your changes?

No. It is my mistake. I found another mistake. encoding field in Main.java
should:

 private String encoding = System.getProperty("file.encoding");

> And for my own curiosity... is there any reason you're not using UTF-8?

We use platform default encoding in general. For example, Japanese 
MS Windows default encoding is Windows-31J and it is also default encoding
in eclipse. Most of Japanese programmer use default encoding. It is the
reason why we use other than utf-8 encoding.

regards,

Takashi Okamoto

----------------------------------------------------------------------

Comment By: Mark Doliner (thekingant)
Date: 2007-02-28 18:12

Message:
Logged In: YES 
user_id=20979
Originator: NO

Interesting patch... I guess the case you're trying to fix is where the
Java source files are saved in an encoding other than UTF-8, but the
Cobertura report is generated as UTF-8, so the source code embedded in the
report shows up as gibberish?

Is the line "private String encoding =
System.getProperty("file.encoding");" at the top of HTMLReport.java needed?
 Or is that left over from an earlier version of your changes?

And for my own curiosity... is there any reason you're not using UTF-8?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1670817&group_id=130558

[ cobertura-Patches-1670817 ] support encoding for multibyte character

[SourceForge.net <no...@so...>]

Patches item #1670817, was opened at 2007-02-28 05:15
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1670817&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 encoding for multibyte character

Initial Comment:
Hi,

Previous patch is for 1.8. This patch is rewrite for SVN snapshot.

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 character.

Please take attached patch.

regards,

Takashi Okamoto

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-10-08 01:07

Message:
Logged In: NO 

I need this patch. Window's default encoding is Windows-31J in Japan and
java sources are written by Windows-31J in general.
javac, java, ant , maven and other tools support configurable encoding.
Emma another coverage tool also suport encoding option.

IMO, support only utf-8 is lazy implementation.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-03-03 03:42

Message:
Logged In: NO 

> I guess the case you're trying to fix is where the
> Java source files are saved in an encoding other than UTF-8, but the
> Cobertura report is generated as UTF-8, so the source code 
> embedded in the
> report shows up as gibberish?

Yes. 

> Is the line "private String encoding =
> System.getProperty("file.encoding");" at the top of
> HTMLReport.java needed?
> Or is that left over from an earlier version of your changes?

No. It is my mistake. I found another mistake. encoding field in Main.java
should:

 private String encoding = System.getProperty("file.encoding");

> And for my own curiosity... is there any reason you're not using UTF-8?

We use platform default encoding in general. For example, Japanese 
MS Windows default encoding is Windows-31J and it is also default encoding
in eclipse. Most of Japanese programmer use default encoding. It is the
reason why we use other than utf-8 encoding.

regards,

Takashi Okamoto

----------------------------------------------------------------------

Comment By: Mark Doliner (thekingant)
Date: 2007-02-28 09:12

Message:
Logged In: YES 
user_id=20979
Originator: NO

Interesting patch... I guess the case you're trying to fix is where the
Java source files are saved in an encoding other than UTF-8, but the
Cobertura report is generated as UTF-8, so the source code embedded in the
report shows up as gibberish?

Is the line "private String encoding =
System.getProperty("file.encoding");" at the top of HTMLReport.java needed?
 Or is that left over from an earlier version of your changes?

And for my own curiosity... is there any reason you're not using UTF-8?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1670817&group_id=130558

[ cobertura-Patches-1807973 ] Report generation performance improvement

[SourceForge.net <no...@so...>]

Patches item #1807973, was opened at 2007-10-05 11:31
Message generated for change (Comment added) made by jirimares
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1807973&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: None
Priority: 5
Private: No
Submitted By: Ignat Zapolsky (windwalker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Report generation performance improvement

Initial Comment:
Hello!

I have found that report generation for a lot of classes (more than 5k) is not very fast, so I run profiling to determine bottlenecks.
After 2 adjustments I have won ~30 seconds (out of  90 secs) in report generation under Ant and much more if tool is run from command line.



----------------------------------------------------------------------

>Comment By: Jiri Mares (jirimares)
Date: 2007-10-05 17:21

Message:
Logged In: YES 
user_id=819956
Originator: NO

I Have just applied the patch into the trunk. Thanks a lot.

----------------------------------------------------------------------

Comment By: Ignat Zapolsky (windwalker)
Date: 2007-10-05 11:57

Message:
Logged In: YES 
user_id=196708
Originator: YES

Profiling records for original code. (Same condition as for modified code)
File Added: profiling-original.zip

----------------------------------------------------------------------

Comment By: Ignat Zapolsky (windwalker)
Date: 2007-10-05 11:52

Message:
Logged In: YES 
user_id=196708
Originator: YES

Java profiler report for optimized code (for situation when generating
HTML files from scratch)
File Added: profiling-optimized.zip

----------------------------------------------------------------------

Comment By: Ignat Zapolsky (windwalker)
Date: 2007-10-05 11:34

Message:
Logged In: YES 
user_id=196708
Originator: YES

Another diff.
File Added: diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1807973&group_id=130558

[ cobertura-Patches-1807973 ] Report generation performance improvement

[SourceForge.net <no...@so...>]

Patches item #1807973, was opened at 2007-10-05 12:31
Message generated for change (Comment added) made by windwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1807973&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: Ignat Zapolsky (windwalker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Report generation performance improvement

Initial Comment:
Hello!

I have found that report generation for a lot of classes (more than 5k) is not very fast, so I run profiling to determine bottlenecks.
After 2 adjustments I have won ~30 seconds (out of  90 secs) in report generation under Ant and much more if tool is run from command line.



----------------------------------------------------------------------

>Comment By: Ignat Zapolsky (windwalker)
Date: 2007-10-05 12:57

Message:
Logged In: YES 
user_id=196708
Originator: YES

Profiling records for original code. (Same condition as for modified code)
File Added: profiling-original.zip

----------------------------------------------------------------------

Comment By: Ignat Zapolsky (windwalker)
Date: 2007-10-05 12:52

Message:
Logged In: YES 
user_id=196708
Originator: YES

Java profiler report for optimized code (for situation when generating
HTML files from scratch)
File Added: profiling-optimized.zip

----------------------------------------------------------------------

Comment By: Ignat Zapolsky (windwalker)
Date: 2007-10-05 12:34

Message:
Logged In: YES 
user_id=196708
Originator: YES

Another diff.
File Added: diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1807973&group_id=130558

[ cobertura-Patches-1807973 ] Report generation performance improvement

[SourceForge.net <no...@so...>]

Patches item #1807973, was opened at 2007-10-05 12:31
Message generated for change (Comment added) made by windwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1807973&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: Ignat Zapolsky (windwalker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Report generation performance improvement

Initial Comment:
Hello!

I have found that report generation for a lot of classes (more than 5k) is not very fast, so I run profiling to determine bottlenecks.
After 2 adjustments I have won ~30 seconds (out of  90 secs) in report generation under Ant and much more if tool is run from command line.



----------------------------------------------------------------------

>Comment By: Ignat Zapolsky (windwalker)
Date: 2007-10-05 12:52

Message:
Logged In: YES 
user_id=196708
Originator: YES

Java profiler report for optimized code (for situation when generating
HTML files from scratch)
File Added: profiling-optimized.zip

----------------------------------------------------------------------

Comment By: Ignat Zapolsky (windwalker)
Date: 2007-10-05 12:34

Message:
Logged In: YES 
user_id=196708
Originator: YES

Another diff.
File Added: diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1807973&group_id=130558

[ cobertura-Patches-1807973 ] Report generation performance improvement

[SourceForge.net <no...@so...>]

Patches item #1807973, was opened at 2007-10-05 12:31
Message generated for change (Comment added) made by windwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1807973&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: Ignat Zapolsky (windwalker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Report generation performance improvement

Initial Comment:
Hello!

I have found that report generation for a lot of classes (more than 5k) is not very fast, so I run profiling to determine bottlenecks.
After 2 adjustments I have won ~30 seconds (out of  90 secs) in report generation under Ant and much more if tool is run from command line.



----------------------------------------------------------------------

>Comment By: Ignat Zapolsky (windwalker)
Date: 2007-10-05 12:34

Message:
Logged In: YES 
user_id=196708
Originator: YES

Another diff.
File Added: diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1807973&group_id=130558

[ cobertura-Patches-1807973 ] Report generation performance improvement

[SourceForge.net <no...@so...>]

Patches item #1807973, was opened at 2007-10-05 12:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1807973&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: Ignat Zapolsky (windwalker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Report generation performance improvement

Initial Comment:
Hello!

I have found that report generation for a lot of classes (more than 5k) is not very fast, so I run profiling to determine bottlenecks.
After 2 adjustments I have won ~30 seconds (out of  90 secs) in report generation under Ant and much more if tool is run from command line.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1807973&group_id=130558

[ cobertura-Patches-1784301 ] Support for multiple .ser files simultaneously

[SourceForge.net <no...@so...>]

Patches item #1784301, was opened at 2007-08-29 18:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1784301&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: Andrew Craig (andrewscraig)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for multiple .ser files simultaneously

Initial Comment:
With the current version of Cobertura, if you want to generate different "cobertura.ser" files per jar file, you need to call cobertura-instrument separately.  When you have a large number of jar files, this results in a substantial overhead simply starting/shutting down the JVM.

The reason I was thinking this functionality would be useful is so that if you have two applications (say a collection of EJBs and a User Interface), with some common libraries in between -- you want to instrument all of the jar files, but need to generate completely different reports (the report in the UI project doesn't care about the coverage for the EJB project).  If we were to use the same cobertura.ser file, the UI report would mark the EJB project as being 0% covered.

Attached is a patch to allow (optionally) creating one "destfile" file per jar file.

Another small change is that if there were no classes to instrument, don't bother writing the .ser file out (it's just a waste of a file).  If preferred, I could change this so that it's an option, rather than changing the default behaviour?

I have not created any unit tests for this -- if there is interest in this, I can do so.

This patch is against the 1.9 branch, but it should (I believe) work on the trunk as well.


To use it, two additional properties have been added:

--splitDataFile (to enable the multipe datafile option)
--saveEmptyCoverage (if there is no instrumented output, don't bother writing the coverage.ser file).

Let me know if you've any questions on any of this!

Andrew


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1784301&group_id=130558

[ cobertura-Patches-1764802 ] Ignore branches on ignored lines

[SourceForge.net <no...@so...>]

Patches item #1764802, was opened at 2007-07-31 14:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1764802&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: Sam (itguysam2)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ignore branches on ignored lines

Initial Comment:
In my code base (java 1.4) we use a log class with an assert replacement along the lines of "Log.check(thingy != null)." If I use the "ignore" regex it ignores this line for purposes of counting but it still instruments the conditonals and marks them as untouched branches in the report (the counts are not affected however). I went into the 1.9 release source and created a patch that fixes this issue. I don;t have any SVN tools on my machine so its not easy for me to make a patch file but the fix is only 5 lines of code so it shouldn't be too difficult to do by hand. There may be a better way of handling this during reporting but this patch solved my problem.


FirstPassMethodInstrumenter.java{
//add a vector for holding current jumpLabels
Vector thisLineJumps = new Vector();
//in function visitJumpInsn(opcode, Label label){
//between classData.addLineJump() and jumpTargetLabels.put insert:
if(!thisLineJumps.contains(label)) thisLineJumps.add(label);
//}

//in function visitMethodInsn(){
//after classData.removeLine(currentLine);
for (int i = 0; i < thisLineJumps.size(); i++){
   jumpTargetLabels.remove(thisLineJumps.elementAt(i));
}
//}
}
SecondPassMethodInstrumenter.java{
//in function vistJumpInsn(opcode,Label)
// after <clinit> check in if statment add:

}&& this.firstPass.getJumpTargetLabels().containsKey(label)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1764802&group_id=130558

[ cobertura-Patches-1493790 ] added dirset to ReportTask

[SourceForge.net <no...@so...>]

Patches item #1493790, was opened at 2006-05-23 15:19
Message generated for change (Comment added) made by binarydreams
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1493790&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: added dirset to ReportTask

Initial Comment:
Hi, 

My project doesn't have a single src directory and it's
inconvenient to add a fileset for each of them. The
attached patch allows ReportTask (and others) to take a
Dirset child element. I use it like so:

      <cobertura-report format="html"
destdir="${output_dir}/converage"
datafile="${coverage_data_file}" maxMemory="256m">
        <dirset dir="${project_root_dir}">
          <include name="**/src"/>
        </dirset>
      </cobertura-report>

As you can see, I'm supplying a list of src directories
rather than files.

I hope this is useful to others as well.

-Matt
(This patch also includes the previous patch I
submitted which allows one to set the forked jvm's heap
size)

----------------------------------------------------------------------

Comment By: Jeff Myers (binarydreams)
Date: 2007-05-31 12:18

Message:
Logged In: YES 
user_id=40971
Originator: NO

Any chance of having this integrated into a release in the near future?
This feature is a critical need for my application as well.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1493790&group_id=130558

[Cobertura-patches] [ cobertura-Patches-1727276 ] Testing cobertura-patches mailing list

[SourceForge.net <no...@so...>]

Patches item #1727276, was opened at 2007-05-29 03:02
Message generated for change (Settings changed) made by thekingant
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1727276&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: Mark Doliner (thekingant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Testing cobertura-patches mailing list

Initial Comment:
test

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1727276&group_id=130558

[Cobertura-patches] [ cobertura-Patches-1727276 ] Testing cobertura-patches mailing list

[SourceForge.net <no...@so...>]

Patches item #1727276, was opened at 2007-05-29 03:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1727276&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: Mark Doliner (thekingant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Testing cobertura-patches mailing list

Initial Comment:
test

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=1727276&group_id=130558