Extending sonar.sources in multi-module project

SonarQube
1

Hi,
I use Community Edition Version 9.6.1 (build 59531).

This question was asked already on Stackoverflow a while ago (java - sonar-maven-plugin: extending sonar.sources in multi-module project - Stack Overflow), got a helpful answer but now is facing deprecation warnings:

The original question
I want to extend sonar.sources, which by default is pom.xml,src/main/java, by src/main/resources in order to check XML files that are located there.

This seemingly simple task turned out to be difficult since I have a multi-module maven project (> 100 modules, nested) with a lot of them don’t have a src/main/resources folder and most of them not even a src folder (e.g. for packaging=pom). This leads to a build error if I set sonar.sources to pom.xml,src/main/java,src/main/resources or pom.xml,src/main:
I want to extend sonar.sources, which by default is pom.xml,src/main/java, by src/main/resources in order to check XML files that are located there.

This seemingly simple task turned out to be difficult since I have a multi-module maven project (> 100 modules, nested) with a lot of them don’t have a src/main/resources folder and most of them not even a src folder (e.g. for packaging=pom). This leads to a build error if I set sonar.sources to pom.xml,src/main/java,src/main/resources or pom.xml,src/main:

[ERROR] Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.5:sonar (default-cli) on project xyz-parent: The directory 'C:\...\submodule\src\main\resources' does not exist for Maven module ... Please check the property sonar.sources -> [Help 1]

The original answer
One of the things you can do it:

  • In your root POM, define the following properties:
    ** sonar.sources to be .
    ** sonar.inclusions to be src/main/** => this will include all the known files that SQ finds in your modules in the src/main folder if it exists
  • In your modules, if you want to control better what gets in, you just have to use/override sonar.exclusions or sonar.inclusions

The deprecation warnings
Now I’m facing the deprecation warnings
[WARNING] Specifying module-relative paths at project level in the property 'sonar.inclusions' is deprecated. To continue matching files like 'my-submodule1/src/main/java/com/foo/Foo.java', update this property so that patterns refer to project-relative paths

My question
Do I really have to list all paths my-submodule1/src/main,my-submodule2/src/main,...,my-submodule100/src/main in sonar.sources separately in favor of sonar.inclusions? This is error-prone, if there are modules added and one will forget to add it to sonar.sources.

2

Hey there.

My first thought was to do exactly this:

<properties>
  <sonar.sources>.</sonar.sources>
  <sonar.inclusions>pom.xml,src/main/**</sonar.inclusions>
</properties>

Indeed this both:

  • Works
  • Produces deprecation warnings

This problem has a tricky history. SonarQube has its roots in Java and the ecosystems surrounding it (Maven/Gradle,Ant), and everything else was added later. Now it no longer makes sense to have something that revolves around a java-ecosystem concept, which is why we’re trying to move away from the concept of modules. It takes time to weed something deep in the roots of how things work out of SonarQube.

What you can do is use a variable available to Maven to set the path correctly for each module:

In the root pom.xml…

<properties>
  <sonar.sources>.</sonar.sources>
  <sonar.inclusions>${maven.multiModuleProjectDirectory}/pom.xml,${maven.multiModuleProjectDirectory}/src/main/**</sonar.inclusions>
</properties>

Hope this helps!

Edit: As pointed out later, this solution doesn’t work.

3

Hi,

Thanks for the reply.

But this does not work. ${maven.multiModuleProjectDirectory} points to the root directory of the project (see [MNG-6589] Document property maven.multiModuleProjectDirectory - ASF JIRA), so no sub-modules are properly included. sonar.scanner.dumpToFile is confirming that.

Regards
Jonny

4

Ah you’re right, sorry. I had it in my head this morning that pointed to the root directory of each module. I’m a bit rusty on my Maven!

In that case – I would suggest you use the deprecated method for now. I’ll flag this for attention as I’m not sure what we would recommend doing once the deprecation moves to removal (it seems really inconvenient to have to adjust the pom.xml of every submodule).

6

In that case – I would suggest you use the deprecated method for now.

Thanks, this was also our decision.