Fix for multi-module maven builds.

[evansnicholas]

Fix to ensure that scoverage produces correct results when used in the context of a multi-module maven build with dependencies between the modules (for instance classes that inherit from classes in other modules).

[evansnicholas]

This fix is for a problem that a colleague of mine contacted you about a few weeks ago (you had some email contact). I am not certain if this is the best way to fix the problem, but it does fix it for us. Hopefully this fix will help you understand what we are struggling with, and maybe suggest a better fix.

[sksamuel]

Can you clarify this for me. If the writer has not yet been set for that thread, you setting it only if there are no measurement files yet. What happens if the writer has not been set for that thread, and there are measurement files?

[evansnicholas]

Indeed, this fix was made with single threaded execution in mind and therefore may not be good enough. I was uncomfortable adding more state to the Invoker object to take multi-threading into account. The fundamental problem seems to be that measurement results get written to the wrong directory when certain kinds of relationships exist between sub-modules of a maven project. I have created a very simple maven project that illustrates the problem but could not upload it here. What is the best way of sending this to you?

[evansnicholas]

I have closed the pull request because I believe this is not the optimum solution to the problem. However, I hope that the maven project I put together helps you understand what we are struggling with. Just for clarity: the project contains two sub-modules parent and child, each containing one scala class with one method and a test for that method. The class in the child module extends the class in the parent module. If you run mvn clean test in the root directory of the mvn project you will see that code coverage for the parent is generated correctly but that the coverage results for the child are incorrect. It claims that there is zero coverage for the child but this is clearly incorrect. If you remove the inheritance relation between the classes then the coverage is correct. More subtle still: the parent class now contains one string val. If you remove this val the coverage for the child is also generated correctly.