Question about saving measures for modules and directories


I am one of the developers of the Sonargraph plugin (
Sonargraph computes metric values for different levels, amongst them module-level metrics. InputModule is deprecated since SonarQube API 7.6 and we refactored our Sensor to only run on project-level. This led to a substantially smaller code base (great!). Now, I got the request that also module-level metrics should be imported into SonarQube. Is there any way to get to the modules from the project configuration?
I would really need to know each module’s base directory to have a directory (InputComponent) that our plugin can save the measure to. Is that supported?
Or would I need to adjust our plugin to be executed per module again in order to get access to each module’s base directory?

While researching the forum for answers to above question, I came across one answer of Julien Henry “but in 7.9 only files and projects are supported”
(What exactly does saving on `context.module() ' do?).
What does this mean for the module metrics mentioned above? As I understand it, the support for them will be gone soon?
Is there a recommended way to import metric values for directories (e.g. Java Packages) into SonarQube?

Thanks for any help!

Best regards

Hi! I don’t think it’s possible. The concept of “module” just doesn’t exist in SonarQube 7.6.

Release 7.6 Upgrade Notes

Concept of module removed from the UI
This version drops the concept of module from the interface. There is no longer a homepage presentation for any level below the project itself. Additionally, the presentation of the project has been updated in the Measures and Code pages to display the project tree as it is in the file system. For the most part (see below) analysis of multi-module projects will continue to work as it has.

Hi Felipe,

thanks for trying to help. I saw the upgrade notes that you quote, that’s why we changed from module-based scanner to project-based scanner.

But the quote also says, that “analysis of multi-module projects will continue to work as it has”. Which means, e.g. for Maven or Gradle based systems, there is still support for “modules”.
It’s just not 100% clear to me, what kind of abstractions will exist in the future in SonarQube that issues and measures can be attached to in a scanner: Project and files only?
What does this mean for plugins that provide metrics on other abstraction levels (e.g. modules and directories)?
Do we need to implement the computation of those metrics as a MeasureComputer?
We would need to repeat the computation that we already have inside our product: So far we simply export all info into a report and processed that in the SonarQube plugin to import the values into SonarQube.

Some migration guidance for existing plugins would be great. If it already exists, a link to the resource is highly appreciated.


Not exactly… The SonarQube Scanner still reads the “sonar.modules” property and most of the analysis properties continue to work as before, but module and directory-level metrics aren’t calculated anymore. There’s no way to save or view this data on the SonarQube Server.

I can’t point to a documentation though, it’s my experience as a plugin developer.

Hi Felipe,

thanks again!
As far as I understand the API, the MeasureComputer is a way to aggregate metric values from source files to a higher-level (e.g. directory) which are then shown on the SonarQube Server. There just won’t be a way to attach measures to a directory directly in the scanner-side anymore.
But maybe one of the core SonarQube developers has some additional advice which way to go?

Thanks, Ingmar


can anyone please provide more info?
If this isn’t the right place to ask these questions, where would that be?

Thanks a lot!

Hi @ingmarkellner

On server side, we only want to retain file level or project level issues/measures. Computing intermediate measures (folder/module) is fine during the scanner or compute engine aggregation, but we stopped providing a way to persist (and display) them in the UI.

The concept of Java package is a logical concept, that doesn’t play well with our multi-language approach/physical FS layout (a package can be physically in multiple folders).

Same for the concept of modules, this is not a universal concept, it depends on the build tool. Even the concept of module basedir is not always meaningful (or you can have multiple modules in the same basedir, or you may have common files shared in multiple modules, or a file part of a module, but in a different basedir, …).

If you want to persist logical measures (measures of packages or modules), I suggest you create a complex measure at project level (that contains serialized data).