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

[ cobertura-Feature Requests-2766248 ] integration tests for maven plugin

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

Feature Requests item #2766248, was opened at 2009-04-15 15:23
Message generated for change (Tracker Item Submitted) made by davetron5000
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2766248&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: Dave Copeland (davetron5000)
Assigned to: Nobody/Anonymous (nobody)
Summary: integration tests for maven plugin

Initial Comment:
It seems you cannot determine coverage of both integration and unit tests using the maven plugin.  Wondering why this is and if this is a planned feature?

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

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

[ cobertura-Feature Requests-2711629 ] Deploy Cobertura 1.9.1 release on Maven central repository

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

Feature Requests item #2711629, was opened at 2009-03-25 11:08
Message generated for change (Comment added) made by mustaghattack
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2711629&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: Stevo Slavic (sslavic)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deploy Cobertura 1.9.1 release on Maven central repository

Initial Comment:
Please deploy Cobertura 1.9.1 release on Maven central repository. It would be nice to have this task as part of the Cobertura release process in future too.

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

Comment By: Bruno Bieth (mustaghattack)
Date: 2009-03-31 12:17

Message:
I've added 1.9.1 in my enterprise repository. I've used the following pom :

<?xml version="1.0" ?>
<project>
  <modelVersion>4.0.0</modelVersion>

  <groupId>net.sourceforge.cobertura</groupId>
  <artifactId>cobertura</artifactId>
  <version>1.9.1</version>
  <name>Cobertura</name>

  <description>
    Cobertura is a free Java tool that calculates the percentage of code
accessed by tests.
    It can be used to identify which parts of your Java program are
lacking test coverage. It is based on jcoverage.
  </description>

  <url>http://cobertura.sourceforge.net</url>

  <licenses>
    <license>
      <name>The GNU General Public License, Version 2</name>
      <url>http://www.gnu.org/licenses/gpl.txt</url>
      <distribution>repo</distribution>
    </license>
  </licenses>

  <dependencies>
    <dependency>
      <groupId>oro</groupId>
      <artifactId>oro</artifactId>
      <version>2.0.8</version>
    </dependency>
    <dependency>
      <groupId>asm</groupId>
      <artifactId>asm</artifactId>
      <version>3.0</version>
    </dependency>
    <dependency>
      <groupId>asm</groupId>
      <artifactId>asm-tree</artifactId>
      <version>3.0</version>
    </dependency>
    <dependency>
      <groupId>log4j</groupId>
      <artifactId>log4j</artifactId>
      <version>1.2.9</version>
    </dependency>
    <dependency>
      <groupId>org.apache.ant</groupId>
      <artifactId>ant</artifactId>
      <version>1.7.0</version>
    </dependency>
  </dependencies>

</project>


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

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

[ cobertura-Feature Requests-2711629 ] Deploy Cobertura 1.9.1 release on Maven central repository

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

Feature Requests item #2711629, was opened at 2009-03-25 12:08
Message generated for change (Tracker Item Submitted) made by sslavic
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2711629&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: Stevo Slavic (sslavic)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deploy Cobertura 1.9.1 release on Maven central repository

Initial Comment:
Please deploy Cobertura 1.9.1 release on Maven central repository. It would be nice to have this task as part of the Cobertura release process in future too.

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

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

[ cobertura-Feature Requests-2694565 ] Adding incremental instrumentation

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

Feature Requests item #2694565, was opened at 2009-03-19 10:27
Message generated for change (Tracker Item Submitted) made by trungdinhtrong
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.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2694565&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 18:18
Message generated for change (Comment added) made by nobody
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: Nobody/Anonymous (nobody)
Date: 2009-03-03 11: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 22: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 13: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-2581199 ] Allow tabs size to be controlled.

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

Feature Requests item #2581199, was opened at 2009-02-09 11:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2581199&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 tabs size to be controlled.

Initial Comment:
In the colorized code output tabs in source code are output as 8 spaces.  If would be nice if the tab size could be controlled in some way.

(In my code base indentation is by tabs, with 1 tab = 4 spaces.  Consequentially the Cobertura output looks stretched.)

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

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

[ cobertura-Feature Requests-2581177 ] Include simple 'count' stats for classes.

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

Feature Requests item #2581177, was opened at 2009-02-09 11:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2581177&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: Include simple 'count' stats for classes.

Initial Comment:
It would be nice of the class level report page and/or the package level page included (as well as 'Line Coverage', 'Branch Coverage' and 'Complexity') some simple counts for the classes:

- number of constructors.
- number of public/protected/package/private methods.

Possibly also:

- number of fields (of each access level).
- number of imports.

It would be especially useful if these were sortable columns.

This information is useful when doing code reviews.


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

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

[ cobertura-Feature Requests-2515098 ] mention of forkmode attribute

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

Feature Requests item #2515098, was opened at 2009-01-16 19:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2515098&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: Trevor Leach (trevor_leach)
Assigned to: Nobody/Anonymous (nobody)
Summary: mention of forkmode attribute 

Initial Comment:
The "Ant Task Reference" page should mention the junit task's forkmode attribute.  By setting it to "once" instead of letting it default to "perTest," significant speed improvements can be made on larger code bases.  This one change cut our build time by three-quarters, and really lowered the unit-test resistance levels of my developers.

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

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

[ cobertura-Feature Requests-2030120 ] Support for Eclipse PDE

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

Feature Requests item #2030120, was opened at 2008-07-28 11:01
Message generated for change (Settings changed) made by nchaitas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2030120&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: Works For Me
Priority: 5
Private: No
Submitted By: nchaitas (nchaitas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for Eclipse PDE 

Initial Comment:
Hi!
We develop an Eclipse based project with OSGi bundles etc and we tried to introduce Cobertura to it with no success. While there were no problems by simple Junit tests, there were class loading problems by tests that need to get run as JUnit plugin tests. I searched around and I found out that other developers had the same problems too (http://dev.eclipse.org/newslists/news.eclipse.tptp/msg02546.html). Therefore they had to go for EMMA, which seems to deal with these problems thanks to its "in place" (overwrite mode) instrumentation in offline mode and its installation as an extension to JRE (http://dev.eclipse.org/newslists/news.eclipse.platform/msg44478.html) . 
Does Cobertura provide any similar solution for it and if not, is there any intention to face this problem?

Thank you in advance,
neo

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

>Comment By: nchaitas (nchaitas)
Date: 2009-01-16 18:18

Message:
Hi everybody!
I have also been able to make Cobertura work with the Eclipse PDE, that's
why I am closing this report (which I had opened myself).
The changes I 've made were:
#1: I 've also instrumented the jars in place, although I don't know if
that was essential or not.
#2: I copied the cobertura.jar and its 4 external libs next to each other
(flat) in <my_jdk>\jre\lib\ext
#3: I've entered in the ant-target call "core-test" of the "suite" target
in the test.xml file of our tests plugin following properties:
	<target name="suite">
		...
		<ant target="core-test" antfile="${library-file}"
dir="${eclipse-home}">
			...
			<property name="vmargs" value="-classpath
${instrumented}/*.jar;${jars}/*.jar -Dosgi.parentClassloader=app
-Dnet.sourceforge.cobertura.datafile=${coberturaScripts}\cobertura.ser"/>
			<property name="jvm" value="${javaCmd}"/>
		</ant>
	</target>
			
Setting -Dosgi.parentClassloader=ext has also worked. However app has been
preferred, because the VM sets up the classloaders with the following
hierarchy: app->ext->boot. Since there were occasionally several
class-loading problems the securest option has been preferred.
It is of course very important to make sure that the value of ${javaCmd}
is <my_jdk>\jre\bin\java, that means the jre installation where you have
copied the cobertura libs (s. #2). Personally I had problems with that,
because the property ${jvm} of my Ant installation had been "secretly"
referring to another java installation.
		
What could still not work is the approach of following the example of
Cobertura's tutorial (Ant Task Reference#Running Tests), that means calling
the <junit> ant task, since this one knows nothing about the Eclipse Test
Framework that is necessary for the Eclipse tests automation (actually it
had not been that easy to get the  Eclipse tests automation to work
anyway!).
I tried to set the same properties as above, but (as expected) with no
success:
		<junit fork="yes" dir="${coberturaScripts}" jvm="${jvmHome}"
failureProperty="test.failed">
			<sysproperty key="osgi.parentClassloader" 
				value="app" />
			<sysproperty key="net.sourceforge.cobertura.datafile"
				file="${coberturaScripts}/cobertura.ser" />
			...
		</junit>
	</target>

On the other hand, the approach that worked (the one with the 3 changes I
've mentioned above) calls at the very end the <java> ant task in the
org.eclipse.test_3.2.0\library.xml of the Eclipse Test Framework like
this:
		<java fork="true" dir="." timeout="${timeout}" jvm="${jvm}"
logError="true"
			classname="org.eclipse.core.launcher.Main"
output="${junit-report-output}/${classname}.txt">
	        <classpath>
	    		<fileset dir="${eclipse-home}/plugins">
	            	<include name="org.eclipse.equinox.launcher_*.jar"/>
	          	</fileset>
	        </classpath>
				...
		    <jvmarg line="${vmargs} ${extraVMargs}"/>
		</java>


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

Comment By: Andreas Pakulat (andipak)
Date: 2008-08-04 17:14

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

I was now able to make cobertura work, though I'm not sure what of the
various things I tried made it finally run.

My setup now puts cobertura-main.jar from a self-built cobertura into
<jre>/lib/ext and I've changed test.xml from the eclipse-unit testing to
sets the vmargs property before calling the test-plugin's test.xml file
<property name="vmargs"
value="-Dnet.sourceforge.cobertura.datafile=${cobertura.datafile}
-Dosgi.parentClassloader=ext" />

I think thats all modifications I did.

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

Comment By: Andreas Pakulat (andipak)
Date: 2008-07-30 17:50

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

As opposed to the posted snippet I'm directly replacing the plugin .jar's
by the instrumented ones. And I can reproduce the problem why just
executing the java command on the commandline. So it seems eclipse is
somehow not loading the cobertura and related jar's. 

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

Comment By: Andreas Pakulat (andipak)
Date: 2008-07-30 17:42

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

Missed that sourceforge wouldn't ask me for login before sending the
comment. So that last one was from me.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-07-30 17:41

Message:
Logged In: NO 

I'm having the same problem, even adding cobertura.jar along with the asm,
jakarta and log4j jars to the ext/ dir and using that bootloader doesn't
seem to help here.

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

Comment By: nchaitas (nchaitas)
Date: 2008-07-30 17:29

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

Hi!
One more piece of information that might be useful.
Cobertura gets executed through use of the <junit> Ant task (according to
its instructions), while Eclipse automated tests get executed through the
<java> Ant task (also with fork="true" and , which accept the Ant elements
<jvmarg>, <sysproperty> and <classpath>, which I used to specify the type
of the class loader, the location of the cobertura.ser and of my
instrumented classes respectively. In particular the invocation of this
<java> task looked like this (in my very first attempt):
		<java fork="true" dir="." timeout="${timeout}" jvm="${jvm}"
logError="true"
			classname="org.eclipse.core.launcher.Main"
output="${junit-report-output}/${classname}.txt">
	        <classpath>
    		  	<fileset dir="${eclipse-home}/plugins">
            	<include name="org.eclipse.equinox.launcher_*.jar"/>
          	</fileset>
	        </classpath>
		    <arg line="-application ${application}"/>
		    <arg line="-data ${data-dir}"/>
		    <arg line="formatter=${formatter},${test-output}"/>
		    <arg line="-testPluginName ${plugin-name}"/>
		    <arg line="-className ${classname}"/>
		    <arg line="-os ${os}"/>
		    <arg line="-ws ${ws}"/>
		    <arg line="-arch ${arch}"/>
		    <arg line="-consolelog"/>
		    <jvmarg line="${vmargs} ${extraVMargs}"/>
		    <sysproperty key="PLUGIN_PATH" value="${plugin-path}"/> 
			 	<!-- Define cobertura specific elements -->
				<sysproperty key="net.sourceforge.cobertura.datafile"
file="${coberturaScripts}/cobertura.ser" />
		    <classpath>
		      <fileset dir="${instrumented}">
		        <include name="**/*.jar"/>
		      </fileset>
		      <fileset dir="${jars}">
		        <include name="**/*.jar"/>
		      </fileset>
	    	</classpath>
				<classpath refid="cobertura.classpath" />
		</java>

As long as I don't instrument my classes and I don't define any cobertura
specific elements in this <java> task my tests run normally.
When I instrument my classes and I use the <junit> task as described in
the cobertura instructions then (after getting an output of many exceptions
on the console upon initialization) only some of my tests get executed, I
assume these are the ones that can get executed as junit tests as well as
junit (Eclipse) plugin tests.

I hope that something of all these could be useful... :o)
Regards,
neo

PS: By the way -even if this does not actually belong to this discussion-,
I had problems with the <cobertura-report> task, particularly with defining
the set of the source files of my multiple eclipse plugin-projects. This
problem is documented very good here
(https://sourceforge.net/mailarchive/forum.php?thread_name=780385.62813.qm%40web56601.mail.re3.yahoo.com&forum_name=cobertura-devel)
by another user and the solution proposed there (namely the use of groovy
ant task) did work for me, indeed! However, I believe that allowing the Ant
element <dirset> to <cobertura-report> task would be the clean solution for
defining multiple source packages. In my opinion a feature request upon
that too is not such a bad idea, since the use of the <cobertura-merge>
task to merge multiple coverage data files is not so convenient.


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

Comment By: nchaitas (nchaitas)
Date: 2008-07-29 13:55

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

Hi John,

thanks for your response.
Unfortunately I am not familiar with the way the code coverage tools
instrument the classes, but it seems that you do, so I appreciate a
lot your assistance!

The EMMA link you mentioned is:
http://emma.sourceforge.net/userguide/ar01s02s03.html (for command line)
and
http://emma.sourceforge.net/userguide/ar01s03s03.html (for ANT)

The in-place instrumentation is not the reason it doesn't work, since
I manually replace the original classes with the instrumented ones.

In Eclipse there are 4 ways to define the classloader type (s.
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04389.html).
EMMA works for eclipse, when it gets installed on the ext/ directory
of the JRE and the Eclipse classloader type is set to "ext" (however
EMMA's got just one jar, while cobertura.jar depends on 4 other jars).
I tried putting cobertura.jar on the JRE/ext directory and setting the
Eclipse classloader type to "ext" and it didn't work.
My classes could still not find
cobertura.jar\net\sourceforge\cobertura\coveragedata\HasBeenInstrumented.class.

I also tried for instance to create an Eclipse cobertura plugin (a wrapper

of cobertura.jar and its 4 required jars under lib/), add it as a
dependency 
to my plugins and then integrate it to my build process (without any
references 
to it of course). While in the Eclipse IDE my plugins set to depend on my
new 
cobertura plugin could reference class coveragedata\HasBeenInstrumented
the 
generated byte code instrumented into my plugins in the scope of the
testing 
process still did not work.

I read somewhere that EMMA and cobertura generate pretty different
instrumented byte codes, so I just guessed, that the way the generated 
byte code references the cobertura classes was the problem.
For this reason and because it seems I was not the only one who tried
to integrate cobertura to Eclipse PDE (Plugin Development Environment)
I posted this issue under feature requests and not as a bug.

I hope that that could clear up things a little bit.
Kind regards,
neo

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

Comment By: John Lewis (lewijw)
Date: 2008-07-28 14:22

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

Can you give me the link for EMMA's instructions for offline mode
operation?

It is possible to have Cobertura instrument in place.   Just don't use the
todir attribute of <cobertura-instrument>.

I'm not a plugin developer, but I imagine you need to make sure Cobertura
is loaded by the root classloader.  I'm not sure how to do that with
Eclipse.

I would like to get this working.

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

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

[ cobertura-Feature Requests-2477310 ] Add support for mutation testing

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

Feature Requests item #2477310, was opened at 2008-12-30 15:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2477310&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: Add support for mutation testing

Initial Comment:
Please consider adding support for mutation testing.  Mutation testing involves many of the same technologies as measuring coverage.  There are Java mutation testing packages available, but they are all relatively hard to use.  Carma appears to be an exception to this, but is currently closed source and in very early development.

http://en.wikipedia.org/wiki/Mutation_testing
http://retroduction.org/archives/carma_handson_codec.html


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

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

[ cobertura-Feature Requests-1172106 ] Feature to disable coverage on specific methods/classes

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

Feature Requests item #1172106, was opened at 2005-03-28 16:13
Message generated for change (Comment added) made by lewijw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1172106&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: Feature to disable coverage on specific methods/classes 

Initial Comment:
I would like to be able to remove methods or whole
classes from coverage consideration. 

This would be quite useful for declerative methods that
are never to be called but present to enforce a
contract. For example a private default constructor for
a utility class (with static methods only) that makes
sure that no objects can be created for the specific
type or a no-op implementation of an illegal method
that throws an UnsupportedOperationException. 

Presently, these declerative methods show up as
untested in the statistics. I would like to be able to
instruct Cobertura that these methods are to be removed
(grayed out) from all reports and statistics. 

One way would be to allow this to be configured in XML
or maybe even better by JDK1.5 tiger annotations (the
specific annotation used would best be configured so
that users can declare an annotation of their own
instead of making their source dependable on Cobertura).

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

>Comment By: John Lewis (lewijw)
Date: 2008-12-25 06:39

Message:
Exclude *.class - not *.java.

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

Comment By: wenxing zheng (wenxing)
Date: 2008-12-25 03:11

Message:
the org/openspml/v2/client/*.java is under the build.classes.dir.
But I don't want them to be included in the coverage report.
I have excluded them on the instrmen and report ant task, but it doesn't
work.
How can i achieve my goal?

Mail: wen...@ns...

Thanks 


<fileset dir="${build.classes.dir}">
     <include name="**/*.class" />
     <exclude name="**/*Test.class" />
     <exclude name="org/openspml/v2/client/*.java"/> 
</fileset>

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

Comment By: Ho Tri Bao (hotribao)
Date: 2008-12-05 10:25

Message:
I submitted a patch for this here
https://sourceforge.net/tracker2/?func=detail&aid=2353196&group_id=130558&atid=720017

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-12-05 10:16

Message:
I submitted a patch for this here:
http://sourceforge.net/tracker2/?func=detail&aid=2353196&group_id=130558&atid=720017

There are other features included in that patch

Bao.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2006-03-31 04:35

Message:
Logged In: NO 

I'm searching for this feature too. An ant task option will 
be perfect with getter/setter disable and a regexp matcher.

It's not a simple feature but enforce the concept of code 
coverage : simple beans most not be included in reports and 
generates wrong statistics and useless "red spots", 
decreasing usability : you must check class one by one to 
see if statistics are relevant ...


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

Comment By: Stephen Colebourne (scolebourne)
Date: 2005-11-28 14:14

Message:
Logged In: YES 
user_id=408725

I agree with this feature request. Getters and setters
should not be tested. Ideally I would like to see a regex
method matcher, so I can also exclude other methods (eg.
*Property methods in our application)

Thanks for Cobertura

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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-09-05 10:15

Message:
Logged In: NO 

Lines that throw exceptions may also be removed from
untested code.I

I also agree that private constructors should not appear in
the report, at least there shoul be a option to do that.

Mickal

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

Comment By: Julien Rentrop (julienrentrop)
Date: 2005-05-11 06:04

Message:
Logged In: YES 
user_id=1276478

Filtering out classes should already be possible by using a
fileset element in the instrument task and exclude the
classes which you don't want to analyze.

An addition to your comment: A lot of Java methods are just
getters and setters. We are not going to write these simple
methods. But int he coverage reports the lines of codes of
the getters and setters are counted which do decrease the
coverage percentage.

It would be nice to have the option to remove getters and
setters from coverage considiration.

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

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

[ cobertura-Feature Requests-1172106 ] Feature to disable coverage on specific methods/classes

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

Feature Requests item #1172106, was opened at 2005-03-28 22:13
Message generated for change (Comment added) made by wenxing
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1172106&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: Feature to disable coverage on specific methods/classes 

Initial Comment:
I would like to be able to remove methods or whole
classes from coverage consideration. 

This would be quite useful for declerative methods that
are never to be called but present to enforce a
contract. For example a private default constructor for
a utility class (with static methods only) that makes
sure that no objects can be created for the specific
type or a no-op implementation of an illegal method
that throws an UnsupportedOperationException. 

Presently, these declerative methods show up as
untested in the statistics. I would like to be able to
instruct Cobertura that these methods are to be removed
(grayed out) from all reports and statistics. 

One way would be to allow this to be configured in XML
or maybe even better by JDK1.5 tiger annotations (the
specific annotation used would best be configured so
that users can declare an annotation of their own
instead of making their source dependable on Cobertura).

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

Comment By: wenxing zheng (wenxing)
Date: 2008-12-25 08:11

Message:
the org/openspml/v2/client/*.java is under the build.classes.dir.
But I don't want them to be included in the coverage report.
I have excluded them on the instrmen and report ant task, but it doesn't
work.
How can i achieve my goal?

Mail: wen...@ns...

Thanks 


<fileset dir="${build.classes.dir}">
     <include name="**/*.class" />
     <exclude name="**/*Test.class" />
     <exclude name="org/openspml/v2/client/*.java"/> 
</fileset>

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

Comment By: Ho Tri Bao (hotribao)
Date: 2008-12-05 15:25

Message:
I submitted a patch for this here
https://sourceforge.net/tracker2/?func=detail&aid=2353196&group_id=130558&atid=720017

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-12-05 15:16

Message:
I submitted a patch for this here:
http://sourceforge.net/tracker2/?func=detail&aid=2353196&group_id=130558&atid=720017

There are other features included in that patch

Bao.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2006-03-31 10:35

Message:
Logged In: NO 

I'm searching for this feature too. An ant task option will 
be perfect with getter/setter disable and a regexp matcher.

It's not a simple feature but enforce the concept of code 
coverage : simple beans most not be included in reports and 
generates wrong statistics and useless "red spots", 
decreasing usability : you must check class one by one to 
see if statistics are relevant ...


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

Comment By: Stephen Colebourne (scolebourne)
Date: 2005-11-28 19:14

Message:
Logged In: YES 
user_id=408725

I agree with this feature request. Getters and setters
should not be tested. Ideally I would like to see a regex
method matcher, so I can also exclude other methods (eg.
*Property methods in our application)

Thanks for Cobertura

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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-09-05 16:15

Message:
Logged In: NO 

Lines that throw exceptions may also be removed from
untested code.I

I also agree that private constructors should not appear in
the report, at least there shoul be a option to do that.

Mickal

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

Comment By: Julien Rentrop (julienrentrop)
Date: 2005-05-11 12:04

Message:
Logged In: YES 
user_id=1276478

Filtering out classes should already be possible by using a
fileset element in the instrument task and exclude the
classes which you don't want to analyze.

An addition to your comment: A lot of Java methods are just
getters and setters. We are not going to write these simple
methods. But int he coverage reports the lines of codes of
the getters and setters are counted which do decrease the
coverage percentage.

It would be nice to have the option to remove getters and
setters from coverage considiration.

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

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

[ cobertura-Feature Requests-1439558 ] List of untested packages, classes, and methods

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

Feature Requests item #1439558, was opened at 2006-02-27 18:28
Message generated for change (Comment added) made by hotribao
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1439558&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: Elliotte Rusty Harold (elharo)
Assigned to: Nobody/Anonymous (nobody)
Summary: List of untested packages, classes, and methods

Initial Comment:
I would like to add as part of the HTML output an
additional page somewhere that lists all completely
untested (0% coverage) packages, classes, constructors,
and methods. This would be helpful in testing legacy
code and identifying places wehre tests are most
needed. Currently one has to drill down to get all this
information. It would be nice to have it in one place. 

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

Comment By: Ho Tri Bao (hotribao)
Date: 2008-12-09 23:45

Message:
Another idea is listing top project risks (like what is done by Clover).
Top project risks are top classes/methods that are complex but have less
line coverage rate. So it is the relationship between code complexity and
code coverage.

I made a patch for this. It was submitted here:
https://sourceforge.net/tracker/index.php?func=detail&aid=2353196&group_id=130558&atid=720017

You can either take the SVN diff take the compiled JAR

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

Comment By: Nobody/Anonymous (nobody)
Date: 2007-01-12 21:10

Message:
Logged In: NO 

Don't stop at 0%... it would be great to have the % configurable via the
ant task so one could quickly see all the classes that fall below some
threshold.

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

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

[ cobertura-Feature Requests-1172106 ] Feature to disable coverage on specific methods/classes

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

Feature Requests item #1172106, was opened at 2005-03-29 04:13
Message generated for change (Comment added) made by hotribao
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1172106&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: Feature to disable coverage on specific methods/classes 

Initial Comment:
I would like to be able to remove methods or whole
classes from coverage consideration. 

This would be quite useful for declerative methods that
are never to be called but present to enforce a
contract. For example a private default constructor for
a utility class (with static methods only) that makes
sure that no objects can be created for the specific
type or a no-op implementation of an illegal method
that throws an UnsupportedOperationException. 

Presently, these declerative methods show up as
untested in the statistics. I would like to be able to
instruct Cobertura that these methods are to be removed
(grayed out) from all reports and statistics. 

One way would be to allow this to be configured in XML
or maybe even better by JDK1.5 tiger annotations (the
specific annotation used would best be configured so
that users can declare an annotation of their own
instead of making their source dependable on Cobertura).

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

Comment By: Ho Tri Bao (hotribao)
Date: 2008-12-05 22:25

Message:
I submitted a patch for this here
https://sourceforge.net/tracker2/?func=detail&aid=2353196&group_id=130558&atid=720017

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-12-05 22:16

Message:
I submitted a patch for this here:
http://sourceforge.net/tracker2/?func=detail&aid=2353196&group_id=130558&atid=720017

There are other features included in that patch

Bao.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2006-03-31 16:35

Message:
Logged In: NO 

I'm searching for this feature too. An ant task option will 
be perfect with getter/setter disable and a regexp matcher.

It's not a simple feature but enforce the concept of code 
coverage : simple beans most not be included in reports and 
generates wrong statistics and useless "red spots", 
decreasing usability : you must check class one by one to 
see if statistics are relevant ...


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

Comment By: Stephen Colebourne (scolebourne)
Date: 2005-11-29 02:14

Message:
Logged In: YES 
user_id=408725

I agree with this feature request. Getters and setters
should not be tested. Ideally I would like to see a regex
method matcher, so I can also exclude other methods (eg.
*Property methods in our application)

Thanks for Cobertura

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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-09-05 22:15

Message:
Logged In: NO 

Lines that throw exceptions may also be removed from
untested code.I

I also agree that private constructors should not appear in
the report, at least there shoul be a option to do that.

Mickal

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

Comment By: Julien Rentrop (julienrentrop)
Date: 2005-05-11 18:04

Message:
Logged In: YES 
user_id=1276478

Filtering out classes should already be possible by using a
fileset element in the instrument task and exclude the
classes which you don't want to analyze.

An addition to your comment: A lot of Java methods are just
getters and setters. We are not going to write these simple
methods. But int he coverage reports the lines of codes of
the getters and setters are counted which do decrease the
coverage percentage.

It would be nice to have the option to remove getters and
setters from coverage considiration.

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

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

[ cobertura-Feature Requests-1172106 ] Feature to disable coverage on specific methods/classes

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

Feature Requests item #1172106, was opened at 2005-03-28 21:13
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1172106&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: Feature to disable coverage on specific methods/classes 

Initial Comment:
I would like to be able to remove methods or whole
classes from coverage consideration. 

This would be quite useful for declerative methods that
are never to be called but present to enforce a
contract. For example a private default constructor for
a utility class (with static methods only) that makes
sure that no objects can be created for the specific
type or a no-op implementation of an illegal method
that throws an UnsupportedOperationException. 

Presently, these declerative methods show up as
untested in the statistics. I would like to be able to
instruct Cobertura that these methods are to be removed
(grayed out) from all reports and statistics. 

One way would be to allow this to be configured in XML
or maybe even better by JDK1.5 tiger annotations (the
specific annotation used would best be configured so
that users can declare an annotation of their own
instead of making their source dependable on Cobertura).

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-12-05 15:16

Message:
I submitted a patch for this here:
http://sourceforge.net/tracker2/?func=detail&aid=2353196&group_id=130558&atid=720017

There are other features included in that patch

Bao.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2006-03-31 09:35

Message:
Logged In: NO 

I'm searching for this feature too. An ant task option will 
be perfect with getter/setter disable and a regexp matcher.

It's not a simple feature but enforce the concept of code 
coverage : simple beans most not be included in reports and 
generates wrong statistics and useless "red spots", 
decreasing usability : you must check class one by one to 
see if statistics are relevant ...


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

Comment By: Stephen Colebourne (scolebourne)
Date: 2005-11-28 19:14

Message:
Logged In: YES 
user_id=408725

I agree with this feature request. Getters and setters
should not be tested. Ideally I would like to see a regex
method matcher, so I can also exclude other methods (eg.
*Property methods in our application)

Thanks for Cobertura

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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-09-05 15:15

Message:
Logged In: NO 

Lines that throw exceptions may also be removed from
untested code.I

I also agree that private constructors should not appear in
the report, at least there shoul be a option to do that.

Mickal

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

Comment By: Julien Rentrop (julienrentrop)
Date: 2005-05-11 11:04

Message:
Logged In: YES 
user_id=1276478

Filtering out classes should already be possible by using a
fileset element in the instrument task and exclude the
classes which you don't want to analyze.

An addition to your comment: A lot of Java methods are just
getters and setters. We are not going to write these simple
methods. But int he coverage reports the lines of codes of
the getters and setters are counted which do decrease the
coverage percentage.

It would be nice to have the option to remove getters and
setters from coverage considiration.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1172106&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 18:18
Message generated for change (Comment added) made by nobody
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: Nobody/Anonymous (nobody)
Date: 2008-12-02 22: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 13: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-2353057 ] Many in one: Ignoring methods; risky classes/methods; ...

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

Feature Requests item #2353057, was opened at 2008-11-27 15:44
Message generated for change (Comment added) made by hotribao
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2353057&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: 9
Private: No
Submitted By: Ho Tri Bao (hotribao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Many in one: Ignoring methods; risky classes/methods; ...

Initial Comment:
Cobertura is great. However, we are looking forward for the integration of these features to the future release of Cobertura. They are very useful feature for us. When going through the list of feature requests and patches, I found similar ideas. But they are separate while we need all of them. Hence I develop a patch which contains all of them and I would like to contribute them here:


==================================
1. Bug fix for zero-complexity bug
   - Cobertura usually reports zero-complexity for source codes written in Java5 (due to new syntaxes)
   - Cobertura reports the complexity as average value (e.g. total complexity of the class divides by number of methods in the class). This could give a false sense: A class with one complex method and many getters/setters can become a simple class. So, the accumulated complexity should be shown instead (although it can give a false sense also! But at least more reasonable, a class with many simple methods can become complex)
   
   This should be put in the "Bugs" section. However, I would like to mention it here since the result of fixing this bug will be used in the following features.
   This can be same as the problem reported here http://sourceforge.net/tracker/index.php?func=detail&aid=2207940&group_id=130558&atid=720015

==================================
2. Ignoring certain methods from coverage calculation
   Currently, all methods in a class are taken into account when calculating the coverage rate. However, in pragmatic testing, there are trivial methods that we never test. We should be able to exclude these methods from calculating the coverage rate.
   There are 3 things:
     - It should be possible to specify which methods in which classes that will be ignored. Notice the case of overloading methods
     - Information about ignored methods (which methods are ignored) should be shown in the HTML report
     - The HTML report should also shown the list of ignored methods order by their complexity. This is to prevent mistaking when declaring ignored methods (since regular expression/wildcards can be used). This is also used to check that if some people in a team intentionally ignored complex methods that they should test :-)

   This can be same as the requested feature: http://sourceforge.net/tracker/index.php?func=detail&aid=1172106&group_id=130558&atid=720018

==================================
3. Listing risky classes/methods
   Showing how many percentages of codes are covered by test is very good. But not enough in pragmatic test: it should also show which classes, which methods that require more tests. Bugs normally come from complex methods. Hence if a class/method is complex but does not have high coverage rate (line coverage is enough), one should consider testing it.
   
   This is something like what is done by Clover: http://www.atlassian.com/software/clover/features/hotspots.jsp
   This is also similar to the features requested here: http://sourceforge.net/tracker/index.php?func=detail&aid=1439558&group_id=130558&atid=720018 and here http://sourceforge.net/tracker/index.php?func=detail&aid=1182501&group_id=130558&atid=720018
   

==================================
4. On-the-fly instrumentation
   Currently, Cobertura only work in offline mode. Meaning all classes must be instrumented before being run. This leads to some limitations:
   - Lose time when developing unit test: imagine a developer is writing unit test for one class in a big project with Maven for example. Then in order to get the coverage report he has to type mvn cobertura:cobertura which will provoke the compilation process. Just to get coverage report of one class, he has to compile the whole project. And normally, many things happen at the compilation time: jsp compile, checkstyle check, pmd check... So, it's time waste.
     The ideal case is that: the developer just runs the unit test within Eclipse then he gets the coverage report for the class that he tests.
     
   - Cobertura can be used not only for unit test coverage but also for other tests (FAT, for example). That could be a risk (and it's not good) that we deliver the instrumented EAR/WAR to our customer. The ideal case is that the class will be instrumented when it is loaded at the first time.
   
   It's similar to the requested feature here: http://sourceforge.net/tracker/index.php?func=detail&aid=1483233&group_id=130558&atid=720018

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

>Comment By: Ho Tri Bao (hotribao)
Date: 2008-11-27 18:01

Message:
I posted the patch here:
https://sourceforge.net/tracker/index.php?func=detail&aid=2353196&group_id=130558&atid=720017

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

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

[ cobertura-Feature Requests-2353057 ] Many in one: Ignoring methods; risky classes/methods; ...

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

Feature Requests item #2353057, was opened at 2008-11-27 15:44
Message generated for change (Settings changed) made by hotribao
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2353057&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: 9
Private: No
Submitted By: Ho Tri Bao (hotribao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Many in one: Ignoring methods; risky classes/methods; ...

Initial Comment:
Cobertura is great. However, we are looking forward for the integration of these features to the future release of Cobertura. They are very useful feature for us. When going through the list of feature requests and patches, I found similar ideas. But they are separate while we need all of them. Hence I develop a patch which contains all of them and I would like to contribute them here:


==================================
1. Bug fix for zero-complexity bug
   - Cobertura usually reports zero-complexity for source codes written in Java5 (due to new syntaxes)
   - Cobertura reports the complexity as average value (e.g. total complexity of the class divides by number of methods in the class). This could give a false sense: A class with one complex method and many getters/setters can become a simple class. So, the accumulated complexity should be shown instead (although it can give a false sense also! But at least more reasonable, a class with many simple methods can become complex)
   
   This should be put in the "Bugs" section. However, I would like to mention it here since the result of fixing this bug will be used in the following features.
   This can be same as the problem reported here http://sourceforge.net/tracker/index.php?func=detail&aid=2207940&group_id=130558&atid=720015

==================================
2. Ignoring certain methods from coverage calculation
   Currently, all methods in a class are taken into account when calculating the coverage rate. However, in pragmatic testing, there are trivial methods that we never test. We should be able to exclude these methods from calculating the coverage rate.
   There are 3 things:
     - It should be possible to specify which methods in which classes that will be ignored. Notice the case of overloading methods
     - Information about ignored methods (which methods are ignored) should be shown in the HTML report
     - The HTML report should also shown the list of ignored methods order by their complexity. This is to prevent mistaking when declaring ignored methods (since regular expression/wildcards can be used). This is also used to check that if some people in a team intentionally ignored complex methods that they should test :-)

   This can be same as the requested feature: http://sourceforge.net/tracker/index.php?func=detail&aid=1172106&group_id=130558&atid=720018

==================================
3. Listing risky classes/methods
   Showing how many percentages of codes are covered by test is very good. But not enough in pragmatic test: it should also show which classes, which methods that require more tests. Bugs normally come from complex methods. Hence if a class/method is complex but does not have high coverage rate (line coverage is enough), one should consider testing it.
   
   This is something like what is done by Clover: http://www.atlassian.com/software/clover/features/hotspots.jsp
   This is also similar to the features requested here: http://sourceforge.net/tracker/index.php?func=detail&aid=1439558&group_id=130558&atid=720018 and here http://sourceforge.net/tracker/index.php?func=detail&aid=1182501&group_id=130558&atid=720018
   

==================================
4. On-the-fly instrumentation
   Currently, Cobertura only work in offline mode. Meaning all classes must be instrumented before being run. This leads to some limitations:
   - Lose time when developing unit test: imagine a developer is writing unit test for one class in a big project with Maven for example. Then in order to get the coverage report he has to type mvn cobertura:cobertura which will provoke the compilation process. Just to get coverage report of one class, he has to compile the whole project. And normally, many things happen at the compilation time: jsp compile, checkstyle check, pmd check... So, it's time waste.
     The ideal case is that: the developer just runs the unit test within Eclipse then he gets the coverage report for the class that he tests.
     
   - Cobertura can be used not only for unit test coverage but also for other tests (FAT, for example). That could be a risk (and it's not good) that we deliver the instrumented EAR/WAR to our customer. The ideal case is that the class will be instrumented when it is loaded at the first time.
   
   It's similar to the requested feature here: http://sourceforge.net/tracker/index.php?func=detail&aid=1483233&group_id=130558&atid=720018

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

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

[ cobertura-Feature Requests-2353057 ] Many in one: Ignoring methods; risky classes/methods; ...

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

Feature Requests item #2353057, was opened at 2008-11-27 15:44
Message generated for change (Settings changed) made by hotribao
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2353057&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: Ho Tri Bao (hotribao)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Many in one: Ignoring methods; risky classes/methods; ...

Initial Comment:
Cobertura is great. However, we are looking forward for the integration of these features to the future release of Cobertura. They are very useful feature for us. When going through the list of feature requests and patches, I found similar ideas. But they are separate while we need all of them. Hence I develop a patch which contains all of them and I would like to contribute them here:


==================================
1. Bug fix for zero-complexity bug
   - Cobertura usually reports zero-complexity for source codes written in Java5 (due to new syntaxes)
   - Cobertura reports the complexity as average value (e.g. total complexity of the class divides by number of methods in the class). This could give a false sense: A class with one complex method and many getters/setters can become a simple class. So, the accumulated complexity should be shown instead (although it can give a false sense also! But at least more reasonable, a class with many simple methods can become complex)
   
   This should be put in the "Bugs" section. However, I would like to mention it here since the result of fixing this bug will be used in the following features.
   This can be same as the problem reported here http://sourceforge.net/tracker/index.php?func=detail&aid=2207940&group_id=130558&atid=720015

==================================
2. Ignoring certain methods from coverage calculation
   Currently, all methods in a class are taken into account when calculating the coverage rate. However, in pragmatic testing, there are trivial methods that we never test. We should be able to exclude these methods from calculating the coverage rate.
   There are 3 things:
     - It should be possible to specify which methods in which classes that will be ignored. Notice the case of overloading methods
     - Information about ignored methods (which methods are ignored) should be shown in the HTML report
     - The HTML report should also shown the list of ignored methods order by their complexity. This is to prevent mistaking when declaring ignored methods (since regular expression/wildcards can be used). This is also used to check that if some people in a team intentionally ignored complex methods that they should test :-)

   This can be same as the requested feature: http://sourceforge.net/tracker/index.php?func=detail&aid=1172106&group_id=130558&atid=720018

==================================
3. Listing risky classes/methods
   Showing how many percentages of codes are covered by test is very good. But not enough in pragmatic test: it should also show which classes, which methods that require more tests. Bugs normally come from complex methods. Hence if a class/method is complex but does not have high coverage rate (line coverage is enough), one should consider testing it.
   
   This is something like what is done by Clover: http://www.atlassian.com/software/clover/features/hotspots.jsp
   This is also similar to the features requested here: http://sourceforge.net/tracker/index.php?func=detail&aid=1439558&group_id=130558&atid=720018 and here http://sourceforge.net/tracker/index.php?func=detail&aid=1182501&group_id=130558&atid=720018
   

==================================
4. On-the-fly instrumentation
   Currently, Cobertura only work in offline mode. Meaning all classes must be instrumented before being run. This leads to some limitations:
   - Lose time when developing unit test: imagine a developer is writing unit test for one class in a big project with Maven for example. Then in order to get the coverage report he has to type mvn cobertura:cobertura which will provoke the compilation process. Just to get coverage report of one class, he has to compile the whole project. And normally, many things happen at the compilation time: jsp compile, checkstyle check, pmd check... So, it's time waste.
     The ideal case is that: the developer just runs the unit test within Eclipse then he gets the coverage report for the class that he tests.
     
   - Cobertura can be used not only for unit test coverage but also for other tests (FAT, for example). That could be a risk (and it's not good) that we deliver the instrumented EAR/WAR to our customer. The ideal case is that the class will be instrumented when it is loaded at the first time.
   
   It's similar to the requested feature here: http://sourceforge.net/tracker/index.php?func=detail&aid=1483233&group_id=130558&atid=720018

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

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

[ cobertura-Feature Requests-2353057 ] Many in one: Ignoring certain methods from coverage calculat

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

Feature Requests item #2353057, was opened at 2008-11-27 15:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2353057&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: Ho Tri Bao (hotribao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Many in one: Ignoring certain methods from coverage calculat

Initial Comment:
Cobertura is great. However, we are looking forward for the integration of these features to the future release of Cobertura. They are very useful feature for us. When going through the list of feature requests and patches, I found similar ideas. But they are separate while we need all of them. Hence I develop a patch which contains all of them and I would like to contribute them here:


==================================
1. Bug fix for zero-complexity bug
   - Cobertura usually reports zero-complexity for source codes written in Java5 (due to new syntaxes)
   - Cobertura reports the complexity as average value (e.g. total complexity of the class divides by number of methods in the class). This could give a false sense: A class with one complex method and many getters/setters can become a simple class. So, the accumulated complexity should be shown instead (although it can give a false sense also! But at least more reasonable, a class with many simple methods can become complex)
   
   This should be put in the "Bugs" section. However, I would like to mention it here since the result of fixing this bug will be used in the following features.
   This can be same as the problem reported here http://sourceforge.net/tracker/index.php?func=detail&aid=2207940&group_id=130558&atid=720015

==================================
2. Ignoring certain methods from coverage calculation
   Currently, all methods in a class are taken into account when calculating the coverage rate. However, in pragmatic testing, there are trivial methods that we never test. We should be able to exclude these methods from calculating the coverage rate.
   There are 3 things:
     - It should be possible to specify which methods in which classes that will be ignored. Notice the case of overloading methods
     - Information about ignored methods (which methods are ignored) should be shown in the HTML report
     - The HTML report should also shown the list of ignored methods order by their complexity. This is to prevent mistaking when declaring ignored methods (since regular expression/wildcards can be used). This is also used to check that if some people in a team intentionally ignored complex methods that they should test :-)

   This can be same as the requested feature: http://sourceforge.net/tracker/index.php?func=detail&aid=1172106&group_id=130558&atid=720018

==================================
3. Listing risky classes/methods
   Showing how many percentages of codes are covered by test is very good. But not enough in pragmatic test: it should also show which classes, which methods that require more tests. Bugs normally come from complex methods. Hence if a class/method is complex but does not have high coverage rate (line coverage is enough), one should consider testing it.
   
   This is something like what is done by Clover: http://www.atlassian.com/software/clover/features/hotspots.jsp
   This is also similar to the features requested here: http://sourceforge.net/tracker/index.php?func=detail&aid=1439558&group_id=130558&atid=720018 and here http://sourceforge.net/tracker/index.php?func=detail&aid=1182501&group_id=130558&atid=720018
   

==================================
4. On-the-fly instrumentation
   Currently, Cobertura only work in offline mode. Meaning all classes must be instrumented before being run. This leads to some limitations:
   - Lose time when developing unit test: imagine a developer is writing unit test for one class in a big project with Maven for example. Then in order to get the coverage report he has to type mvn cobertura:cobertura which will provoke the compilation process. Just to get coverage report of one class, he has to compile the whole project. And normally, many things happen at the compilation time: jsp compile, checkstyle check, pmd check... So, it's time waste.
     The ideal case is that: the developer just runs the unit test within Eclipse then he gets the coverage report for the class that he tests.
     
   - Cobertura can be used not only for unit test coverage but also for other tests (FAT, for example). That could be a risk (and it's not good) that we deliver the instrumented EAR/WAR to our customer. The ideal case is that the class will be instrumented when it is loaded at the first time.
   
   It's similar to the requested feature here: http://sourceforge.net/tracker/index.php?func=detail&aid=1483233&group_id=130558&atid=720018

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

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

Request

[shashank k. <gui...@gm...>]

Sir,

I am a third year engineering student from JIIT (Noida,India) and have
taken up cobertura as my research project. I am a beginner level java
programmer. Would you be so kind to explain as to how your project works(as
i could not find any detailed docs online). I know this will be the most
absurd request you have received till now. But would be so glad if i get any
help.

Thanks

Regards

Shashank Kapoor
+919810470522

[ cobertura-Feature Requests-2228936 ] Instrumentation Agent

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

Feature Requests item #2228936, was opened at 2008-11-06 09:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2228936&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: Maxim Petrashev (mpetrashev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Instrumentation Agent

Initial Comment:
Can we add instrumentation agent in cobertura library? In this case it will be possible to avoid additional steps in build processes: instrument classes, run tests with instrumented and non-instrumented classes. I believe it will be nice and simple feature? 
I have provided simple implementation of such agent in attachement that can be configured very easy in command line:
-javaagent:cobertura.jar

I will be very appriciate for any feedback on this idea.

Kind regards,
Maxim

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

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

[ cobertura-Feature Requests-2073298 ] Better FAQ entry on EMMA

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

Feature Requests item #2073298, was opened at 2008-08-25 09:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2073298&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: Better FAQ entry on EMMA

Initial Comment:
I think it is worth noting that EMMA does not check branch coverage but basic block coverage, e.g. if you have an if statement that always evaluates to true in your tests, then you'll see that you have not tested false in cobertura but not in EMMA.

While this is a major drawback, EMMA is very fast! It allows instrumentation by the class loader, i.e. on the fly. This is especially useful from within an IDE. It is really cool to use EclEMMA, an EMMA plugin for Eclipse. You can directly start your coverage as a new launch type and see the coverage within the code editor!!!

This would be reeeeeealy cool for cobertura to have as well, but this is not what I'm asking for here. I just think that it would be helpful to have a more detailled comment in the FAQs. Someone might want to use both tools, one while writing code and one while integration building.


Kind regards!

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

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

[ cobertura-Feature Requests-2058556 ] Support Scala Code

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

Feature Requests item #2058556, was opened at 2008-08-18 16:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2058556&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: frohoff (frohoff)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support Scala Code

Initial Comment:
Looks like it almost works

http://www.drmaciver.com/2008/08/reusing-javas-tools-cobertura-and-scala/

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

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

[ cobertura-Feature Requests-2030120 ] Support for Eclipse PDE

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

Feature Requests item #2030120, was opened at 2008-07-28 11:01
Message generated for change (Comment added) made by andipak
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2030120&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: nchaitas (nchaitas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for Eclipse PDE 

Initial Comment:
Hi!
We develop an Eclipse based project with OSGi bundles etc and we tried to introduce Cobertura to it with no success. While there were no problems by simple Junit tests, there were class loading problems by tests that need to get run as JUnit plugin tests. I searched around and I found out that other developers had the same problems too (http://dev.eclipse.org/newslists/news.eclipse.tptp/msg02546.html). Therefore they had to go for EMMA, which seems to deal with these problems thanks to its "in place" (overwrite mode) instrumentation in offline mode and its installation as an extension to JRE (http://dev.eclipse.org/newslists/news.eclipse.platform/msg44478.html) . 
Does Cobertura provide any similar solution for it and if not, is there any intention to face this problem?

Thank you in advance,
neo

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

Comment By: Andreas Pakulat (andipak)
Date: 2008-08-04 17:14

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

I was now able to make cobertura work, though I'm not sure what of the
various things I tried made it finally run.

My setup now puts cobertura-main.jar from a self-built cobertura into
<jre>/lib/ext and I've changed test.xml from the eclipse-unit testing to
sets the vmargs property before calling the test-plugin's test.xml file
<property name="vmargs"
value="-Dnet.sourceforge.cobertura.datafile=${cobertura.datafile}
-Dosgi.parentClassloader=ext" />

I think thats all modifications I did.

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

Comment By: Andreas Pakulat (andipak)
Date: 2008-07-30 17:50

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

As opposed to the posted snippet I'm directly replacing the plugin .jar's
by the instrumented ones. And I can reproduce the problem why just
executing the java command on the commandline. So it seems eclipse is
somehow not loading the cobertura and related jar's. 

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

Comment By: Andreas Pakulat (andipak)
Date: 2008-07-30 17:42

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

Missed that sourceforge wouldn't ask me for login before sending the
comment. So that last one was from me.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-07-30 17:41

Message:
Logged In: NO 

I'm having the same problem, even adding cobertura.jar along with the asm,
jakarta and log4j jars to the ext/ dir and using that bootloader doesn't
seem to help here.

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

Comment By: nchaitas (nchaitas)
Date: 2008-07-30 17:29

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

Hi!
One more piece of information that might be useful.
Cobertura gets executed through use of the <junit> Ant task (according to
its instructions), while Eclipse automated tests get executed through the
<java> Ant task (also with fork="true" and , which accept the Ant elements
<jvmarg>, <sysproperty> and <classpath>, which I used to specify the type
of the class loader, the location of the cobertura.ser and of my
instrumented classes respectively. In particular the invocation of this
<java> task looked like this (in my very first attempt):
		<java fork="true" dir="." timeout="${timeout}" jvm="${jvm}"
logError="true"
			classname="org.eclipse.core.launcher.Main"
output="${junit-report-output}/${classname}.txt">
	        <classpath>
    		  	<fileset dir="${eclipse-home}/plugins">
            	<include name="org.eclipse.equinox.launcher_*.jar"/>
          	</fileset>
	        </classpath>
		    <arg line="-application ${application}"/>
		    <arg line="-data ${data-dir}"/>
		    <arg line="formatter=${formatter},${test-output}"/>
		    <arg line="-testPluginName ${plugin-name}"/>
		    <arg line="-className ${classname}"/>
		    <arg line="-os ${os}"/>
		    <arg line="-ws ${ws}"/>
		    <arg line="-arch ${arch}"/>
		    <arg line="-consolelog"/>
		    <jvmarg line="${vmargs} ${extraVMargs}"/>
		    <sysproperty key="PLUGIN_PATH" value="${plugin-path}"/> 
			 	<!-- Define cobertura specific elements -->
				<sysproperty key="net.sourceforge.cobertura.datafile"
file="${coberturaScripts}/cobertura.ser" />
		    <classpath>
		      <fileset dir="${instrumented}">
		        <include name="**/*.jar"/>
		      </fileset>
		      <fileset dir="${jars}">
		        <include name="**/*.jar"/>
		      </fileset>
	    	</classpath>
				<classpath refid="cobertura.classpath" />
		</java>

As long as I don't instrument my classes and I don't define any cobertura
specific elements in this <java> task my tests run normally.
When I instrument my classes and I use the <junit> task as described in
the cobertura instructions then (after getting an output of many exceptions
on the console upon initialization) only some of my tests get executed, I
assume these are the ones that can get executed as junit tests as well as
junit (Eclipse) plugin tests.

I hope that something of all these could be useful... :o)
Regards,
neo

PS: By the way -even if this does not actually belong to this discussion-,
I had problems with the <cobertura-report> task, particularly with defining
the set of the source files of my multiple eclipse plugin-projects. This
problem is documented very good here
(https://sourceforge.net/mailarchive/forum.php?thread_name=780385.62813.qm%40web56601.mail.re3.yahoo.com&forum_name=cobertura-devel)
by another user and the solution proposed there (namely the use of groovy
ant task) did work for me, indeed! However, I believe that allowing the Ant
element <dirset> to <cobertura-report> task would be the clean solution for
defining multiple source packages. In my opinion a feature request upon
that too is not such a bad idea, since the use of the <cobertura-merge>
task to merge multiple coverage data files is not so convenient.


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

Comment By: nchaitas (nchaitas)
Date: 2008-07-29 13:55

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

Hi John,

thanks for your response.
Unfortunately I am not familiar with the way the code coverage tools
instrument the classes, but it seems that you do, so I appreciate a
lot your assistance!

The EMMA link you mentioned is:
http://emma.sourceforge.net/userguide/ar01s02s03.html (for command line)
and
http://emma.sourceforge.net/userguide/ar01s03s03.html (for ANT)

The in-place instrumentation is not the reason it doesn't work, since
I manually replace the original classes with the instrumented ones.

In Eclipse there are 4 ways to define the classloader type (s.
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04389.html).
EMMA works for eclipse, when it gets installed on the ext/ directory
of the JRE and the Eclipse classloader type is set to "ext" (however
EMMA's got just one jar, while cobertura.jar depends on 4 other jars).
I tried putting cobertura.jar on the JRE/ext directory and setting the
Eclipse classloader type to "ext" and it didn't work.
My classes could still not find
cobertura.jar\net\sourceforge\cobertura\coveragedata\HasBeenInstrumented.class.

I also tried for instance to create an Eclipse cobertura plugin (a wrapper

of cobertura.jar and its 4 required jars under lib/), add it as a
dependency 
to my plugins and then integrate it to my build process (without any
references 
to it of course). While in the Eclipse IDE my plugins set to depend on my
new 
cobertura plugin could reference class coveragedata\HasBeenInstrumented
the 
generated byte code instrumented into my plugins in the scope of the
testing 
process still did not work.

I read somewhere that EMMA and cobertura generate pretty different
instrumented byte codes, so I just guessed, that the way the generated 
byte code references the cobertura classes was the problem.
For this reason and because it seems I was not the only one who tried
to integrate cobertura to Eclipse PDE (Plugin Development Environment)
I posted this issue under feature requests and not as a bug.

I hope that that could clear up things a little bit.
Kind regards,
neo

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

Comment By: John Lewis (lewijw)
Date: 2008-07-28 14:22

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

Can you give me the link for EMMA's instructions for offline mode
operation?

It is possible to have Cobertura instrument in place.   Just don't use the
todir attribute of <cobertura-instrument>.

I'm not a plugin developer, but I imagine you need to make sure Cobertura
is loaded by the root classloader.  I'm not sure how to do that with
Eclipse.

I would like to get this working.

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

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