Thanks for your suggestion!

But this doesn't work the sonar report file (sonar-report.json) is only generated for the complete project in our example in proj-parent/target/sonar/sonar-report.json

So this would require to execute SQ analysis for every module seperately.

We have a lot of multi-module projects with this structure and I don't want to set it for each sub-module of these projects.

Ah, that explains why everything is reported as ok for gerrit builds but not for the nightly builds on sonar. Please include the fix in your next release

Sascha Retter thankfuly provided a pull request, which addresses the parent pom in another folder besides other modules. However, if you use multi module builds you usualy have a more nested structure, e.g.

project/pom.xml (parent-pom)
project/plugins/de.somebody.somePlugin/pom.xml (module)
project/plugins/core/de.somebody.someCorePlugin1/pom.xml (module)
project/plugins/core/de.somebody.someCorePlugin2/pom.xml (module)
project/plugins/ui/de.somebody.someUiPlugin/pom.xml (module)

This is not possible right now or with Sascha's pull request, since it only allows for one subdirectory with the same name as the artifact.id. However with his work I was able to produce a crude hack which supports multi module projects.

The hack works by iterating over all reported issues. For each issue the list of gerrit changes is iterated. If a key of the gerrit change contains from the current issues component artifactId/pathToFile the current issues key is modified from pathToFile to the key of the current gerrit change. With component of current issue is groupId:artifactId:pathToFile. Code see attachment. SonarToGerritPublisher.patch

Again, this is only a crude hack and can be improved uppon.

Note: This hack does not work for merge commits since there the entries for the gerrit changes are the commit message and only files edited with the merge commit itself. This does not include files changed on the branches.

Hi,

This also affects complex multimodule projects where the affected module may be nested more than one layer deep.

The root cause is the component tree in the sonar report is not fully resolvable to the path of the file because the module key only maps back to the first parent.

I have pushed a PR which includes a sample report, test and possible fix. The fix will work in 99% of cases but is not 100% accurate if paths have extreme similarities.
https://github.com/jenkinsci/sonar-gerrit-plugin/pull/32

v 2.1 option "allow auto-match" is added