cobertura-featurerequests — Automated emails from our feature request tracking system

[ cobertura-Feature Requests-3290498 ] Add sortable complexity & coverage to frame-sourcefiles.html

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

Feature Requests item #3290498, was opened at 2011-04-20 20:22
Message generated for change (Comment added) made by yetanothermatt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3290498&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:
There's currently no way to quickly identify which classes have the worst coverage or complexity - you have to drill down into each package to see branch & coverage details of classes (and line coverage, while present, cannot be sorted). I suggest amending frame-sourcefiles.html so that it includes a sortable table with line, branch and complexity.

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

>Comment By: Matthew Smith (yetanothermatt)
Date: 2011-04-20 20:28

Message:
I have added patch 3290509 to implement this.

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

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

[ cobertura-Feature Requests-3290498 ] Add sortable complexity & coverage to frame-sourcefiles.html

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

Feature Requests item #3290498, was opened at 2011-04-20 20:22
Message generated for change (Tracker Item Submitted) made by yetanothermatt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3290498&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:
There's currently no way to quickly identify which classes have the worst coverage or complexity - you have to drill down into each package to see branch & coverage details of classes (and line coverage, while present, cannot be sorted). I suggest amending frame-sourcefiles.html so that it includes a sortable table with line, branch and complexity.

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

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

[ cobertura-Feature Requests-3122257 ] No messages on System.out by instrumented programs

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

Feature Requests item #3122257, was opened at 2010-11-29 14:07
Message generated for change (Tracker Item Submitted) made by jabt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3122257&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: Johannes Abt (jabt)
Assigned to: Nobody/Anonymous (nobody)
Summary: No messages on System.out by instrumented programs

Initial Comment:
Instrumented programs should not print messages on System.out. Otherwise you cannot use instrumented programs in UNIX-style pipe processing.

I suggest that code added by the instrumentation prints its messages on System.err (see patch). Futhermore, there should be a switch that turns off these messages completely.

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

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

[ cobertura-Feature Requests-3098010 ] A way to ignore certain methods/lines in report

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

Feature Requests item #3098010, was opened at 2010-10-29 15:32
Message generated for change (Comment added) made by dongsj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3098010&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: Luke Lindsay (lindsal)
Assigned to: Nobody/Anonymous (nobody)
Summary:  A way to ignore certain methods/lines in report

Initial Comment:
I have been using cobertura for around a month, so am a relative
newbie.  A feature I would find very useful is a way to distinguish between (a) untested
code that I know about and have decided not to test and (b) untested
code that I plan to write tests for.

Is there way to do this other than at the class level?

If not, I thought a simple way to implement this might be to have a
plain text file listing things to ignore.

The syntax could something like the following:
package.ClassName  //ignore whole class
package.ClassName.main //ignore main method
**.set*  //ignore all setter methods in all classes
file:package/ClassName.java:20,50,56 //ignore lines 20, 50, 56 in file
file:package/ClassName.java:"a = b || c;"  //ignore line(s) matching the expression in quotes in file
file:**/*.java:assert** //ignore assertions in all files

Then in the coverage report, there could be two extra categories:
covered ignored and uncovered ignored (which perhaps could be shaded
grey).

Best,

Luke


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

Comment By: songjie dong (dongsj)
Date: 2010-11-16 10:34

Message:
maybe we could have another mode for instrument because tree pattern would
be better for complex ignore rule, what about you guys？

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

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

[ cobertura-Feature Requests-3098010 ] A way to ignore certain methods/lines in report

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

Feature Requests item #3098010, was opened at 2010-10-29 08:32
Message generated for change (Tracker Item Submitted) made by lindsal
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3098010&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: Luke Lindsay (lindsal)
Assigned to: Nobody/Anonymous (nobody)
Summary:  A way to ignore certain methods/lines in report

Initial Comment:
I have been using cobertura for around a month, so am a relative
newbie.  A feature I would find very useful is a way to distinguish between (a) untested
code that I know about and have decided not to test and (b) untested
code that I plan to write tests for.

Is there way to do this other than at the class level?

If not, I thought a simple way to implement this might be to have a
plain text file listing things to ignore.

The syntax could something like the following:
package.ClassName  //ignore whole class
package.ClassName.main //ignore main method
**.set*  //ignore all setter methods in all classes
file:package/ClassName.java:20,50,56 //ignore lines 20, 50, 56 in file
file:package/ClassName.java:"a = b || c;"  //ignore line(s) matching the expression in quotes in file
file:**/*.java:assert** //ignore assertions in all files

Then in the coverage report, there could be two extra categories:
covered ignored and uncovered ignored (which perhaps could be shaded
grey).

Best,

Luke


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

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

[ cobertura-Feature Requests-3091921 ] cobertura xml example report

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

Feature Requests item #3091921, was opened at 2010-10-21 10:20
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3091921&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: Interface Improvements (example)
Group: Next Release (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: cobertura xml example report

Initial Comment:
I couldn't find an example for an xml report in the home site.
Could you please provide a sample xml report?
There are other projects that generates the cobertura xml reports and it's hard to see if there is a problem without having a sample xml.

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

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

[ cobertura-Feature Requests-3042992 ] Coverage Metrics - condition and loop coverage

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

Feature Requests item #3042992, was opened at 2010-08-11 10:50
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3042992&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: Coverage Metrics - condition and loop coverage

Initial Comment:
Are there any plans to integrate condition and loop coverage into Cobertura?
CodeCover (codecover.org)  already supports these metrics.

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

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

[ cobertura-Feature Requests-3035416 ] Include Classes by Annotation

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

Feature Requests item #3035416, was opened at 2010-07-27 19:58
Message generated for change (Comment added) made by flushdia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3035416&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: Vladimir Tsukur (flushdia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Include Classes by Annotation

Initial Comment:
There is no way to include classes for analysis by class / interface annotations.

Use case: part of the application code is public API. Each class / interface in public API is annotated with @PublicAPI. There is a need to collect code coverage statistics solely for public API code.

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

Comment By: Vladimir Tsukur (flushdia)
Date: 2010-08-02 19:53

Message:
Initial use case requires collecting code coverage only for public classes
but I think it would be good to set it up for all classes regardless of
access modifier.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2010-08-01 01:16

Message:
Do you only want code coverage on classes that have access modifier
"public"?

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

Comment By: Vladimir Tsukur (flushdia)
Date: 2010-07-31 17:36

Message:
Wildcard filter may not be applied because there is an established
convention in the project that says that classes and interfaces as public
API only if they are annotated with specific annotation. The same package
may contain both public API classes and non-public API.

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

Comment By: Paul Benedict (paulbenedict)
Date: 2010-07-31 17:04

Message:
Also, JavaDoc allows grouping via package wildcards. I wonder if a wildcard
filter could be enabled since your public API should follow predictable
naming pattern(s).

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

Comment By: Paul Benedict (paulbenedict)
Date: 2010-07-31 17:02

Message:
An alternative solution is to introduce a @Category annotation ala JUnit
4.8. This annotation is an adhoc categorization. If Cobertura were to have
something similar, you could then target one or several category
combinations for your coverage report.

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

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

[ cobertura-Feature Requests-3035416 ] Include Classes by Annotation

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

Feature Requests item #3035416, was opened at 2010-07-27 16:58
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3035416&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: Vladimir Tsukur (flushdia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Include Classes by Annotation

Initial Comment:
There is no way to include classes for analysis by class / interface annotations.

Use case: part of the application code is public API. Each class / interface in public API is annotated with @PublicAPI. There is a need to collect code coverage statistics solely for public API code.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2010-07-31 22:16

Message:
Do you only want code coverage on classes that have access modifier
"public"?

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

Comment By: Vladimir Tsukur (flushdia)
Date: 2010-07-31 14:36

Message:
Wildcard filter may not be applied because there is an established
convention in the project that says that classes and interfaces as public
API only if they are annotated with specific annotation. The same package
may contain both public API classes and non-public API.

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

Comment By: Paul Benedict (paulbenedict)
Date: 2010-07-31 14:04

Message:
Also, JavaDoc allows grouping via package wildcards. I wonder if a wildcard
filter could be enabled since your public API should follow predictable
naming pattern(s).

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

Comment By: Paul Benedict (paulbenedict)
Date: 2010-07-31 14:02

Message:
An alternative solution is to introduce a @Category annotation ala JUnit
4.8. This annotation is an adhoc categorization. If Cobertura were to have
something similar, you could then target one or several category
combinations for your coverage report.

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

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

[ cobertura-Feature Requests-3035416 ] Include Classes by Annotation

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

Feature Requests item #3035416, was opened at 2010-07-27 19:58
Message generated for change (Comment added) made by flushdia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3035416&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: Vladimir Tsukur (flushdia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Include Classes by Annotation

Initial Comment:
There is no way to include classes for analysis by class / interface annotations.

Use case: part of the application code is public API. Each class / interface in public API is annotated with @PublicAPI. There is a need to collect code coverage statistics solely for public API code.

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

Comment By: Vladimir Tsukur (flushdia)
Date: 2010-07-31 17:36

Message:
Wildcard filter may not be applied because there is an established
convention in the project that says that classes and interfaces as public
API only if they are annotated with specific annotation. The same package
may contain both public API classes and non-public API.

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

Comment By: Paul Benedict (paulbenedict)
Date: 2010-07-31 17:04

Message:
Also, JavaDoc allows grouping via package wildcards. I wonder if a wildcard
filter could be enabled since your public API should follow predictable
naming pattern(s).

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

Comment By: Paul Benedict (paulbenedict)
Date: 2010-07-31 17:02

Message:
An alternative solution is to introduce a @Category annotation ala JUnit
4.8. This annotation is an adhoc categorization. If Cobertura were to have
something similar, you could then target one or several category
combinations for your coverage report.

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

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

[ cobertura-Feature Requests-3035416 ] Include Classes by Annotation

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

Feature Requests item #3035416, was opened at 2010-07-27 11:58
Message generated for change (Comment added) made by paulbenedict
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3035416&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: Vladimir Tsukur (flushdia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Include Classes by Annotation

Initial Comment:
There is no way to include classes for analysis by class / interface annotations.

Use case: part of the application code is public API. Each class / interface in public API is annotated with @PublicAPI. There is a need to collect code coverage statistics solely for public API code.

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

Comment By: Paul Benedict (paulbenedict)
Date: 2010-07-31 09:04

Message:
Also, JavaDoc allows grouping via package wildcards. I wonder if a wildcard
filter could be enabled since your public API should follow predictable
naming pattern(s).

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

Comment By: Paul Benedict (paulbenedict)
Date: 2010-07-31 09:02

Message:
An alternative solution is to introduce a @Category annotation ala JUnit
4.8. This annotation is an adhoc categorization. If Cobertura were to have
something similar, you could then target one or several category
combinations for your coverage report.

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

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

[ cobertura-Feature Requests-3035416 ] Include Classes by Annotation

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

Feature Requests item #3035416, was opened at 2010-07-27 11:58
Message generated for change (Comment added) made by paulbenedict
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3035416&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: Vladimir Tsukur (flushdia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Include Classes by Annotation

Initial Comment:
There is no way to include classes for analysis by class / interface annotations.

Use case: part of the application code is public API. Each class / interface in public API is annotated with @PublicAPI. There is a need to collect code coverage statistics solely for public API code.

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

Comment By: Paul Benedict (paulbenedict)
Date: 2010-07-31 09:02

Message:
An alternative solution is to introduce a @Category annotation ala JUnit
4.8. This annotation is an adhoc categorization. If Cobertura were to have
something similar, you could then target one or several category
combinations for your coverage report.

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

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

[ cobertura-Feature Requests-3035416 ] Include Classes by Annotation

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

Feature Requests item #3035416, was opened at 2010-07-27 19:58
Message generated for change (Tracker Item Submitted) made by flushdia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3035416&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: Vladimir Tsukur (flushdia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Include Classes by Annotation

Initial Comment:
There is no way to include classes for analysis by class / interface annotations.

Use case: part of the application code is public API. Each class / interface in public API is annotated with @PublicAPI. There is a need to collect code coverage statistics solely for public API code.

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

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

[ cobertura-Feature Requests-3028843 ] Option to disable source xref

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

Feature Requests item #3028843, was opened at 2010-07-13 02:42
Message generated for change (Comment added) made by lewijw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3028843&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: Interface Improvements (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Option to disable source xref

Initial Comment:
I find it important to share reports with managers, but I cannot always share the cobertura report because the HTML report always includes a cross-reference of the source code. This has been a major problem for me on several occasions. Setting up a site where the source is available -- in any format -- is a security hazard despite best of intentions to secure the site.

I recommend a configuration flag where the source is not used/hyperlinked.

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

>Comment By: John Lewis (lewijw)
Date: 2010-07-13 04:49

Message:
It is not quite what you are asking for, but when you run
<cobertura-report> or cobertura-report.bat, you can either leave off the
<fileset> or have it point to an empty directory.   Then, a report will
still be created with the information, and when you click on a link that
would have shown the source, it will show a message instead that the source
could not be found.

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

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

[ cobertura-Feature Requests-3028843 ] Option to disable source xref

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

Feature Requests item #3028843, was opened at 2010-07-13 07:42
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3028843&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: Interface Improvements (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Option to disable source xref

Initial Comment:
I find it important to share reports with managers, but I cannot always share the cobertura report because the HTML report always includes a cross-reference of the source code. This has been a major problem for me on several occasions. Setting up a site where the source is available -- in any format -- is a security hazard despite best of intentions to secure the site.

I recommend a configuration flag where the source is not used/hyperlinked.

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

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

Prioritize methods and classes with higher test needs

[Roth P. <pat...@mo...>]

Dear Cobertura developers,

The methods/classes with the highest need for test are the most complex ones. To illustrate that, a method with many execution paths must be thoroughly tested, while getters and setters do not need to.

In order to take code coverage and complexity into account, a metric has been proposed: the "crappiness" (see this link for details: http://www.crap4j.org).

It would be interesting to calculate the crappiness of each method and report it in the HTML tables. This won't be very difficult, because cyclomatic complexity is already calculated and displayed. For classes, the maximum CRAP value of its methods could be retained. That way, it would be easy to identify where testing effort will be most valuable.

This feature would fulfill this request: http://sourceforge.net/mailarchive/forum.php?thread_name=E1L5ecy-0007Ba-6R%40b55xhf1.ch3.sourceforge.com&forum_name=cobertura-featurerequests

Best regards
Patrick


In der elektronischen Korrespondenz kann die im Schriftverkehr übliche Vertraulichkeit nicht gewährleistet werden. Bitte überprüfen Sie daher sorgfältig, welche Mitteilungen und Beilagen Sie per E-Mail senden und erhalten möchten. Falls Sie dieses E-Mail irrtümlicherweise erhalten haben, bitten wir Sie, die absendende Person zu kontaktieren und dieses E-Mail mit allen Anhängen von Ihrem System zu löschen.

Avec la communication par courrier électronique, la confidentialité des informations n'est pas garantie comme elle l'est usuellement dans la correspondance écrite. Veuillez donc être vigilant lorsque vous envoyez ou recevez des communications et pièces jointes par courriel. Si vous avez reçu ce courriel par erreur, nous vous prions de contacter l'expéditeur/trice et de l'effacer avec toutes les pièces jointes de votre système.

[ cobertura-Feature Requests-2999515 ] Allow cobertura-report to take dirset for source dirs

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

Feature Requests item #2999515, was opened at 2010-05-10 21:36
Message generated for change (Comment added) made by flushdia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2999515&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: Allow cobertura-report to take dirset for source dirs

Initial Comment:
I would like the ability to use a dirset as the source dir input for the cobertura report task like this:

        <cobertura:report datafile="${cobertura.datafile}" destdir="${reports.dir}/cobertura">
            <dirset dir="${modules.dir}" includes="**/src/main/java"/>
        </cobertura:report>

We have a multi-module project (each with similar dir structures).  I don't want to have to list each module's src dir in separate filesets as currently required.  For example, currently, I have to do this:

        <cobertura:report datafile="${cobertura.datafile}" destdir="${reports.dir}/cobertura">
            <fileset dir="${modules.dir}/moduleA/src/main/java" includes="**/*.java"/>
            <fileset dir="${modules.dir}/moduleB/src/main/java" includes="**/*.java"/>
            <fileset dir="${modules.dir}/moduleC/src/main/java" includes="**/*.java"/>
            <fileset dir="${modules.dir}/moduleD/src/main/java" includes="**/*.java"/>
            <fileset dir="${modules.dir}/moduleE/src/main/java" includes="**/*.java"/>
            <fileset dir="${modules.dir}/moduleF/src/main/java" includes="**/*.java"/>
            <fileset dir="${modules.dir}/moduleG/src/main/java" includes="**/*.java"/>
        </cobertura:report>

We don't really statically maintain a module list anywhere in our build (we use ivy's buildlist task to construct the module list dynamically).  I don't really want to introduce this static list just for generating coverage data.

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

Comment By: Vladimir Tsukur (flushdia)
Date: 2010-06-14 01:01

Message:
Our team would also benefit from this feature since specifying a list of
hardcoded filesets is a obviously a bad configuration solution.

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

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

[ cobertura-Feature Requests-3009801 ] About the character-code when the report is made

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

Feature Requests item #3009801, was opened at 2010-06-01 07:33
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=3009801&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: About the character-code when the report is made

Initial Comment:
Being able to specify in the net.sourceforge.cobertura.reporting.Main class is only character-code of the input file specification. 
When you make HTML
When writing it, it is used though the HTMLReport class is used. 
The character-code of IOUtil.getPrintWriter is fixed, and it is fixed to "UTF-8", and the character-code in made HTML is fixed to UTF-8. 
Therefore, I want you to be able to specify the character-code when outputting it from the outside. 

===================================================================================================================
net.sourceforge.cobertura.util.IOUtil      
  cobertura version 1.9.4.1
  
177	public static PrintWriter getPrintWriter(File file) throws UnsupportedEncodingException, FileNotFoundException
178	{
179		Writer osWriter = new BufferedWriter (new OutputStreamWriter(new FileOutputStream(file), "UTF-8"), 16384);    ←★
180		PrintWriter pw = new PrintWriter(osWriter, false);
181		return pw;
182	}
183	

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

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

[ cobertura-Feature Requests-2999515 ] Allow cobertura-report to take dirset for source dirs

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

Feature Requests item #2999515, was opened at 2010-05-10 18:36
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2999515&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: Allow cobertura-report to take dirset for source dirs

Initial Comment:
I would like the ability to use a dirset as the source dir input for the cobertura report task like this:

        <cobertura:report datafile="${cobertura.datafile}" destdir="${reports.dir}/cobertura">
            <dirset dir="${modules.dir}" includes="**/src/main/java"/>
        </cobertura:report>

We have a multi-module project (each with similar dir structures).  I don't want to have to list each module's src dir in separate filesets as currently required.  For example, currently, I have to do this:

        <cobertura:report datafile="${cobertura.datafile}" destdir="${reports.dir}/cobertura">
            <fileset dir="${modules.dir}/moduleA/src/main/java" includes="**/*.java"/>
            <fileset dir="${modules.dir}/moduleB/src/main/java" includes="**/*.java"/>
            <fileset dir="${modules.dir}/moduleC/src/main/java" includes="**/*.java"/>
            <fileset dir="${modules.dir}/moduleD/src/main/java" includes="**/*.java"/>
            <fileset dir="${modules.dir}/moduleE/src/main/java" includes="**/*.java"/>
            <fileset dir="${modules.dir}/moduleF/src/main/java" includes="**/*.java"/>
            <fileset dir="${modules.dir}/moduleG/src/main/java" includes="**/*.java"/>
        </cobertura:report>

We don't really statically maintain a module list anywhere in our build (we use ivy's buildlist task to construct the module list dynamically).  I don't really want to introduce this static list just for generating coverage data.

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

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

[ cobertura-Feature Requests-1959691 ] Better Handling of Asserts

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

Feature Requests item #1959691, was opened at 2008-05-07 20:18
Message generated for change (Comment added) made by graffity2199
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1959691&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: 6
Private: No
Submitted By: John Lewis (lewijw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better Handling of Asserts

Initial Comment:

Ian Dickinson wrote:

Sorry if this has been asked before; I did look in the archives but couldn't find anything.

I'm getting low branch coverage on code that includes java asserts to encode invariants. For example:

public void setFoo( String foo ) {
    assert foo != null;
    this.foo = foo;
}


@Test
public void testSetFoo() {
    new MockFoo.setFoo( "bar" );
}

@Test (expected=java.lang.AssertionError.class)
public void testSetFoo() {
    new MockFoo().setFoo( null );
}

I can execute both tests successfully, but cobertura will tell me that line with the assert was executed twice but did not traverse all branches.  I'm passing -ea to the JVM to enable the assertions, which I can see is working since the tests themselves all pass.

I'm using the cobertura 1.9 plugin for Maven2 on Java6 (I've tried both 6u6 and 6u4).

Any suggestions?

Thanks,
Ian


Jeffrey Bennett replied:

To get full coverage, you'd need to run 3 tests:
1.) Asserts off
2.) Asserts on, conditional true
3.) Asserts on, conditional false

You've done #2 and #3

To my knowledge, there's no good way of doing all 3 tests leading to a source of friction between Cobertura and asserts.



Ian replied:

OK, I understand. Would it be possible to have the branch coverage algorithm take this into account? I don't know if the VM args are captured in the .ser file, but if so it might be possible (I'm guessing here, I admit) for the branch coverage calculator to note that there are two possible worlds (your #1 vs #2 + #3), and depending which one is the "real" world adjust the statistics so that the code either tests one of the one possible branches, or two of the possible two.

And if that isn't impossible, can I make it a feature request please? :-)


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

Comment By: Benjamin CROIZET (graffity2199)
Date: 2010-04-16 16:48

Message:
+1 I also have low branch coverage because of asserts
This feature would be very interesting

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

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

Message:
Hi,
Ditto - I'm using the Maven 2 plugin and would like to be able to disable
assertions for the surefire run that cobertura uses. I checked the source
and haven't found any obvious way... is there a known workaround (other
than doing it manually) for this?
Thanks!

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-12-02 23:44

Message:
+1. At least provide an option to just automatically set assertion lines to
green or exclude/ignore them. It's simply not practical to do 1+2+3 as
described above.

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

Comment By: Alan Gutierrez (alangutierrez)
Date: 2008-06-03 15:19

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

Please implement this feature. Ideally, Cobertura would not expect to see
#3 even when asserts were on. An assert is a condition that should never be
true. A very fruitless execerise to test the Java assert mechanism.

Certainly, running Cobertura with asserts off should only test #1 and not
expect #2 or #3.

I would be so happy to see this implemented.

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

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

[ cobertura-Feature Requests-2790549 ] ant: allow to specify multiple directories with sources

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

Feature Requests item #2790549, was opened at 2009-05-12 02:56
Message generated for change (Comment added) made by jeksmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2790549&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: aLeXx (buhhunyx)
Assigned to: Nobody/Anonymous (nobody)
Summary: ant: allow to specify multiple directories with sources

Initial Comment:
I have project directory with set of subproject. Following call doesn't include sources to report:
<dirset id="src.dirset" dir="${prjDir}" >
	<include name="**/src" /> 
</dirset>
<property name="src.dir" refid="src.dirset"/>
<cobertura-report
	format="html"
	datafile="${cobertura.ser}"
	destdir="${testResultsDir}/cobertura-report"
	srcdir="${src.dir}"/>

Can be possible to specify source directories using nested dirset instead of filesets:
<cobertura-report
	format="html"
	datafile="${cobertura.ser}"
	destdir="${testResultsDir}/cobertura-report">
	<dirset dir="${prjDir}" >
		<include name="**/src" /> 
	</dirset>
</cobertura-report>


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

Comment By: Jek (jeksmith)
Date: 2010-03-23 15:21

Message:
This is still a problem with the latest version, 1.9.4.1.  It does appear
there is an absolute pathing problem.  Shawn Castrianni spelled it out in
his message sent to Cobertura-devel May 2009:

<quote>
Subject: bug in dirset support

After spending several hours struggling with why I could not get the new
direst
feature to work to support multiple source directories, I found the
problem.

The code change (SVN rev 544 by lewijw) in CommonMatchingTask.java was
using:

createArgumentsForFilenames( builder,
getDirectoryScanner(fileSet).getIncludedDirectories());

The problem is getIncludedDirectories() returns names RELATIVE to the
dirset's
basedir. Therefore, if you have a multiple dirsets with different
basedirs,
those different basedirs are lost and only the relative directory names
are
passed to the Main class of the reporting engine. This causes none of the
source files to be found since a relative directory name will assume to be
relative to ${basedir}.

A functional test was created in
cobertura/examples/functionaltest1/build.xml
but used ${basedir} as its base directory for the direst:

<target name="coverage-reports-with-dirset"> <run-reports> <dirset
dir="${basedir}"> <include
name="**/src" /> </dirset> </run-reports>

this allowed it to work and did not reveal the problem. I believe the fix
should be to change CommonMatchingTask.java to pass in absolute directory
names
to the reporting engine Main class. Perhaps something like this:

DirectoryScanner dirscanner = getDirectoryScanner(fileSet); String
dirnames[] = dirscanner.getIncludedDirectories(); for(int i = 0 ; i <
dirnames.length; i++) { dirnames[i] = dirscanner.getBasedir() +
File.separator + dirnames[i]; } createArgumentsForFilenames( builder,
dirnames); 

</quote>

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

Comment By: Steffen Pingel (squig)
Date: 2010-01-13 21:03

Message:
The dirset support has a bug: Instead of passing absolute paths to the
reporting application it ignores the base directory on the dirset and uses
a relative path. That means it will only work as expected if your build is
running from the same directory that is set as the base directory on the
dirset. 

Here is a crude but working fix:

Index: cobertura/src/net/sourceforge/cobertura/ant/CommonMatchingTask.java
===================================================================
--- cobertura/src/net/sourceforge/cobertura/ant/CommonMatchingTask.java
(revision 689)
+++ cobertura/src/net/sourceforge/cobertura/ant/CommonMatchingTask.java
(working copy)
@@ -174,7 +174,13 @@
                                         */
                                        throw new BuildException("Dirsets
have to come before filesets");
                                }
-                               createArgumentsForFilenames( builder,
getDirectoryScanner(fileSet).getIncludedDirectories());
+                               DirectoryScanner scanner =
getDirectoryScanner(fileSet);
+                               String[] filenames =
scanner.getIncludedDirectories();
+                               for (int i = 0; i < filenames.length; i++)
+                               {
+                                   filenames[i] = baseDir(fileSet) + "/"
+ filenames[i];
+                               }
+                               createArgumentsForFilenames( builder,
filenames);
                        }
                }
        }


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

Comment By: aLeXx (buhhunyx)
Date: 2009-05-13 01:38

Message:
I think that problem is with relative path. Possible solution
<path id="src.dirset">
	<dirset dir="${srcDir}/plugins" >
		<include name="**/src" />
	</dirset>
</path>
But cobertura-report doesn't support the nested "path" element.


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

Comment By: aLeXx (buhhunyx)
Date: 2009-05-13 00:05

Message:
Actualy latest version used.
I tried different combination but without results.

>From example above:

<dirset id="src.dirset" dir="${prjDir}" >
	<include name="**/src" /> 
</dirset>
<property name="src.dir" refid="src.dirset"/>
<echo>${src.dir}</echo>

[echo]
org.eclipse.swordfish.registry.tooling\src;org.eclipse.swordfish.tooling.target\src;org.eclipse.swordfish.tooling.ui\src

Can you provide me valid sample with dirset?

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

Comment By: John Lewis (lewijw)
Date: 2009-05-12 06:53

Message:
What version of Cobertura are you using?   Dirset support was added to
1.9.1.

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

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

[ cobertura-Feature Requests-2800905 ] Eclipse Plugin

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

Feature Requests item #2800905, was opened at 2009-06-04 07:51
Message generated for change (Comment added) made by jmhofer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2800905&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: Interface Improvements (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: loga (loganathank)
Assigned to: Nobody/Anonymous (nobody)
Summary: Eclipse Plugin

Initial Comment:
Is there eclipse plugin available for cobertura ?. Please let me know...

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

Comment By: Joachim Hofer (jmhofer)
Date: 2010-03-11 22:06

Message:
I'm currently working on one: see http://github.com/jmhofer/eCobertura. 

It already covers Java application launches, can load *.ser files and
allows for viewing coverage in a tree view or as editor coloring.

There's still lots and lots to be done, though...

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

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

[ cobertura-Feature Requests-2694565 ] Adding incremental instrumentation

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

Feature Requests item #2694565, was opened at 2009-03-19 15:27
Message generated for change (Comment added) made by jmhofer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2694565&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: Trung (trungdinhtrong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Adding incremental instrumentation

Initial Comment:
We are developing a prototype Eclipse plugin for Cobertura (it is under testing now and may be open sourced soon). For such a plug-in to be useful, Cobertura needs the ability to instrument only classes that has been changed since the last instrumentation. We noted that Emma has this feature.

Here is the detail of the issue:

Every time I launch a test, I would instrument the classes and generate a coverage report after the execution. The problem is that every time I instrument, Cobertura would re-instrument the whole classpath, even
though only a few classes changed since the previous instrumentation - this is a big performance drawback when Cobertura is used in an interactive mode. There are many projects that takes about 1 minute to be fully 
instrumented.

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

Comment By: Joachim Hofer (jmhofer)
Date: 2010-03-10 13:37

Message:
Cobertura doesn't really have an API, but still, you could just hook into
the Main class of cobertura-instrument directly and call the respective
single-class instrumentation method... - like I do in my own prototype
eclipse plugin over at github. ;)

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

Comment By: Piotr Tabor (ptab)
Date: 2010-03-07 23:17

Message:
Have you tried just exclude from instrumentation all other files then that
one 'incremental'. It should work. 

What's the status of the plugin prototype ?

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

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

[ cobertura-Feature Requests-2694565 ] Adding incremental instrumentation

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

Feature Requests item #2694565, was opened at 2009-03-19 15:27
Message generated for change (Comment added) made by ptab
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2694565&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: Trung (trungdinhtrong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Adding incremental instrumentation

Initial Comment:
We are developing a prototype Eclipse plugin for Cobertura (it is under testing now and may be open sourced soon). For such a plug-in to be useful, Cobertura needs the ability to instrument only classes that has been changed since the last instrumentation. We noted that Emma has this feature.

Here is the detail of the issue:

Every time I launch a test, I would instrument the classes and generate a coverage report after the execution. The problem is that every time I instrument, Cobertura would re-instrument the whole classpath, even
though only a few classes changed since the previous instrumentation - this is a big performance drawback when Cobertura is used in an interactive mode. There are many projects that takes about 1 minute to be fully 
instrumented.

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

Comment By: Piotr Tabor (ptab)
Date: 2010-03-07 23:17

Message:
Have you tried just exclude from instrumentation all other files then that
one 'incremental'. It should work. 

What's the status of the plugin prototype ?

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

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

[ cobertura-Feature Requests-2958759 ] Need silent mode

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

Feature Requests item #2958759, was opened at 2010-02-25 15:28
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2958759&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: Need silent mode

Initial Comment:
Great tool. We use a lot of patten matching from stdout/stder in our tests and it would help if the Cobertura tool could disable the information concerning loading classes, etc ... Otherwise I have to filter out this noise.

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

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