Multi module support

[guwirth]

In the last time we had a lot of issues and discussions about multi module support and path issues. In this discussion I like to collect the use cases which we have to support. I like to ask you to add your samples which should be supported (see also #683, #695, #693, #612, #509, #425, ...).

Here what I know so far:

• we should support relative and absolute paths in sonar-project.properties and reports
• the initial sonar-project.properties defines the root baseDir
• It is possible to define a alternate analysis directory by setiing sonar.projectBaseDir. This allows to have sonar-project.properties on another location and set the root baseDir.
• relative paths are always relative to the current baseDir
• default behaviour in a multi module project to define the baseDir is:
  • Using root baseDir adding module name and source folder. In example 1 below this is root/module1/src and root/module2/src.
  • Overwriting the default for a module by redefinig projectBaseDir. In this case the source setting is ignored. This would be root/modules/mod1 and root/modules/mod2 for the example 2 below.

example 1:

sonar.sources=src
sonar.modules=module1,module2

example 2:

sonar.sources=src
module1.sonar.projectBaseDir=modules/mod1
module2.sonar.projectBaseDir=modules/mod2

Reports

• Should be possible to define the locations of report files relative and absolute, inside and outside of root baseDir:

# baseDir = x:/root
sonar.cxx.XXX.reportPath=reports/xxx-*.xml # x:/root/reports/xxx-*.xml
sonar.cxx.XXX.reportPath=x:/root/reports/xxx-*.xml
sonar.cxx.XXX.reportPath=x:/outside/reports/xxx-*.xml

Paths in reports

• relative paths in reports are always relative to current baseDir

<results>
    <error file=".\src\example.cpp" ... />
</results>

• absolute paths in reports must always be inside of current baseDir

<results>
    <error file="x:\root\src\example.cpp" ... />
</results>

Currently we are using also this reactor pattern. Means we are looking for reports always in current baseDir and root BaseDir. Question in the case of multi module projects is:

• Do we still need this if it is possible to set absolute report paths?
• In case of using always root baseDir: If there are realtive paths in report files are they relative to root baseDir or current baseDir?

So now it is up to you: How do you like to use this plugin?

• Where are the reports located?
• How do you define the files in the reports (absolute/relative, relative to what)?

Looking forward to get your answers.

[jmecosta]

thanks for the summary @guwirth . in my company we try to avoid anything other than flat structure. earlier the vs bootstrapper was introduced that was using modules but we found this to be very constraining for other languages other than c#. Now we are giving a go to the msbuild runner, and it looks promising. I created a wrapper for cxx and msbuild, https://github.com/SonarOpenCommunity/sonar-cxx-msbuild-tasks/tree/master/CxxSonarQubeMsbuidRunner and that heavily uses modules plus it also modifies the basedirs so search paths are totally off when it arrives to cxx plugin, thats the reason for the #695. I will try to make it work as soon as possible.

to be honest ive never liked the idea of hacking sonar-project.properties to define a overly complex module structure. Sonar already defines a directory type that expresses the ideas of modules quite nicely imo.

supporting so many cases just brings even more complextiy to the plugin and loads of bugs as we see. perhaps we should just stick to the simple cases and do them very well?

. flat (relative to root + absolute)
. modules (sonar msbuild runner)

. pom.xml and maven, imo its not a easy case to support because of the so many different ways you can define a project.
. defining modules in the sonar-project.properties is also hard to support. and imo requires loads of maintenance from users and us. so i would not support it.

on the other hand, we are not far from supporting the remaining cases that people raise in the past

[guwirth]

1. We also use the flat mode: point is only that this mode is not an official SonarQube mode.
2. How is the msbuild runner exactly working? How do they setup/use the configuration files?

In general:

• I think we can add additional modes but still have to support the regular multi module use cases
• plugin must be usable without msbuild runner

[jmecosta]

1. all, projects here https://github.com/SonarSource/sonar-examples/tree/master/projects/languages are using flat structure. altought they also have many multi modules examples
2. the msbuild runner does not reuse any of the existing stuff. so settings that we have for cxx plugin will need to be passed via command line arg, or you use the wrapper ive mention (i twill take the props from the file and give them as arguments to the msbuild runner). the strucutre is taken using solution and project files using msbuild.

then we need the support the remaining cases, they are not that many

[guwirth]

Did some tests, see #695

[guwirth]

@Bertk I'm also interested in your opinion to this stuff...

[guwirth]

from @Bertk

• I use relative and absolute paths for the reports
• additional I use multiple test reports for one component ( comma separate) . The ant pattern is useless because the files located in different folders and I use absolute paths for the test results
• the reports for pc-lint, cppcheck, Vera++, RATS are located in basedir. I use post-build events to create this reports within CI builds
• I use a mixture of relative or absolute paths for the files within the reports (vc compiler and pc-lint with absolute paths, Vera++ and CppCheck or RATS with relative paths)

[guwirth]

close with #695