Hello! I've recently started looking into the Cobertura plugin as I need couple features that are missing. Namely:
http://jira.codehaus.org/browse/MCOBERTURA-33 http://jira.codehaus.org/browse/MCOBERTURA-65 http://jira.codehaus.org/browse/MCOBERTURA-66 I'm going to explain now what I want to do and what general plugin development problems I am currently trying to tackle. In this e-mail let's work with the following example project: parent - module1 - module2 module1 has module2 as a dependency module1 and module2 have unit tests (meaning that tests affect only classes within given project) module1 additionally has integration tests (meaning that tests affect classes in both module1 and module2) High-level functionality that I want to achieve boils down to two things: 1. Cobertura test coverage report in module1 shows coverage for all classes that are used in the tests - in particular the classes from module2 which are used in integration tests. 2. Cobertura test coverage report in the parent project shows a report containing merged test coverage data from both module1 and module2. (1) is more or less MCOBERTURA-66, (2) is MCOBERTURA-33 and MCOBERTURA-65. I am willing to implement such functionality and I believe (correct me if I am wrong) it is possible to cover more complicated scenarios (deeper multi module hierarchy etc) if implemented correctly. At least it would be a nice step forward towards better test coverage reporting and using Cobertura's full potential. Now for the technical part. (2) seems pretty straightforward to me at this point, I adapted the old patch from MCOBERTURA-33, wrote integration tests for it and it works as expected. However, some questions remain: cobertura:merge mojo is supposed to be an aggregator one. I'm not sure how does it fit into a life cycle - when is such mojo run? Can I access module1 and module2's project metadata (in general - the whole subtree of given project's submodules) in cobertura:merge mojo code without having it as an aggregator? For (1) the idea is to run tests in module1 having module2's instrumented classes on the classpath. This works fine, I tested it "manually" - by replacing classes in module2's jar with instrumented one. Then Cobertura generated a nice report containing all classes used in module1's tests. The problem is that I'm not sure yet how to do it properly. Should I add some kind of new project artifact (jar-instrumented) produced by the Cobertura plugin and inject it to surefire's classpath somehow to override module2's regular jar dependency when running module1's tests? What about the case when no artifacts are produced in the reactor build? Something like "mvn clean compile site". Then, for functionality (1) to work correctly, I would need to add module2/target/generated-classes/cobertura to test classpath when running module1's tests? Any pointers and suggestions will be greatly appreciated. -- Paweł
signature.asc
Description: PGP signature
