Handle multimodule projects

[oscarlvp]

Given a multimodule project PIT will work with each submodule independently. There are projects in which test cases covering the code of a submodule are placed outside of it. In such cases, mutants that survive the tests placed in the same submodule could be killed by test cases of other submodules. This is an issue that has been around for a while and spotted by the PIT's community several times (See hcoles/pitest#41 hcoles/pitest#224 hcoles/pitest#307 hcoles/pitest#323) Right now we have a workaround in which we treat the entire project as one by merging all classpaths but this has more issues. For one thing, there could be dependency issues when merging the classpaths, on the other hand, the correct working directory for each tests is lost, as PIT assumes the same for every test case.
A possible solution for this problem could address two specific tasks:

• Create a Maven aggregator plugin that gather the dependency information among submodules. With this information, identify for each submodule groups of test cases with their classpath and working directory.
• Complement the Maven plugin by making the tests run in their corresponding working directory. Changing PIT's code for would mean change parts of its design in deep components. A better solution could be to use PIT by running the analysis on each of the groups of test cases identified for each submodule and then aggregate the results. This second approach should be easier but could impact the execution time.

[vmassol]

Note that this issue was raised as a result of the workshop I did with Oscar on XWiki, see my blog post at http://massol.myxwiki.org/xwiki/bin/view/Blog/MutationTestingDescartes

[oscarlvp]

This issue is being tackled in a new Maven plugin developed in context of the STAMP project here