[
https://jira.codehaus.org/browse/MCOBERTURA-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=292969#comment-292969
]
Peter Ansell commented on MCOBERTURA-159:
-----------------------------------------
I have a similar situation that was not fulfilled by MCOBERTURA-65, as James
hinted that it was past the scope of that issue
http://jira.codehaus.org/browse/MCOBERTURA-65?focusedCommentId=286002#comment-286002.
I currently pull in abstract tests using <type>test-jar</type>, and they are
not currently instrumented.
Currently this causes cobetura gives the impression that my code is not covered
by the implementation of these abstract blackbox tests. Currently I simply
extend the abstract test and pass it my implementation without reimplementing
the tests themselves. Blackbox tests are more useful to me than whitebox tests
because they enable me to split tests from their implementations completely. It
is this complete separation that currently foils cobertura and emma.
We might extend the plugin to optionally provide the instrumented classes in a
new jar artifact in a similar way to -tests.jar and -sources.jar, say
-cobertura.jar. Then people could manually pull in these artifacts into their
test scopes using <type>cobertura-jar</type> or
<type>cobertura-test-jar</type>? This would require the instrumented classes to
be put into the local repository, but they would be clearly delineated from the
uninstrumented classes, so they would not interfere with people by default
selecting <type>jar</type>. There may however be issues with people putting the
<type>jar</type> libraries on the compile scope classpath alongside the
instrumented classes, as the compile and runtime scopes overlap with the test
scope.
I am not sure how the process would work internally, but there should be
examples in maven-jar-plugin for how they handle exporting to -tests.jar.
https://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html You may
even be able to reuse part of their mojo code to avoid reimplementing it.
I would be particularly interested to have my tests from dependent modules
available this way. If it catches on we could eventually easily get reports for
the degree to which we utilise upstream libraries as well as local modules!
> Provide support for multi-module project
> ----------------------------------------
>
> Key: MCOBERTURA-159
> URL: https://jira.codehaus.org/browse/MCOBERTURA-159
> Project: Maven 2.x Cobertura Plugin
> Issue Type: Improvement
> Affects Versions: 2.5.1
> Reporter: Jan Goyvaerts
>
> Invoking "clean verify" on the parent of a multi-module project has the
> effect that each module is built isolated from the others. As though the
> targets were invoked for the modules separately. However, I think in the
> context of coverage measurement the semantic should be different.
> If the targets were invoked on the parent project, I think the coverage
> measurement should be done for all the modules together and result in an
> aggregated coverage report. Why else invoke the targets for the parent
> project ?
> Important is that some modules might use each other's classes. Currently it
> looks like the shared classes have no coverage at all. While this is not the
> case. They're just not located in the same module being tested. (Because they
> were not instrumented ?)
> An alternative would be to allow the users to specify dependencies to include
> in the coverage process. Whether it were a sibling module or not. Which is of
> course a recursive process because the included dependency might have
> cobertura configured to include other dependencies as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
