Hi Colin, Thanks for the reply. Let me explain my view on this.
First, MMF-365 is very confusing in terms of making a clear distinction about what the word modules means there. Its mentioned - drop the concept of module in SQ/SC So I’m assuming its only related to dropping the module functionality at SQ/SC
Also while looking in detail I’ve found this page https://docs.sonarqube.org/7.6/setup/upgrade-notes/ which clearly states that
Concept of module removed from the UI
This version drops the concept of module from the interface
…
For the most part (see below) analysis of multi-module projects will continue to work as it has.
Second, “we changed the generic coverage/test reports sensors to be global sensors” - Why?
I can confirm that below properties are still supported at the module level
sonar.sources
sonar.tests
sonar.javascript.lcov.reportPaths
If these are supported at module level then why not sonar.testExecutionReportPaths ?
Third, Is bit funny but I was checking the SonarJS repository and I have found the below code in this pom file - https://github.com/SonarSource/SonarJS/blob/master/pom.xml
<properties>
<!-- this is necessary because of drop of modules -->
<sonar.testExecutionReportPaths>eslint-bridge/test-report.xml</sonar.testExecutionReportPaths>
See the comment, presence of that comment justifies that it should actually belong to the module level.
Forth, and final, I think reverse mapping child modules properties in the parent project is not a good practice. so I believe this needs to be fixed.
Sorry for this big reply, I would love to hear your thoughts on this. Thanks