Specifying module-relative paths at project... is deprecated

I added an exclusion for a single specific file and started getting this warning on the screen.

Specifying module-relative paths at project level in the property ‘sonar.coverage.exclusions’ is deprecated. To continue matching files like ‘AVisualStudioProjectFolder/ACodeFile.cs’, update this property so that patterns refer to project-relative paths.

I dont know what “module” its referring to, this is the path to the file in the repo.

Hi,

Just to be super-clear, you’re getting this warning on the path-from-project-root?

 
Thx,
Ann

Its a path from the repo root to one of many VS projects in the repo.

The repository and sonar project have been totally idle since reporting this, but today its no longer reporting that condition. Either its transient or got fixed. I’d still like to know what a module is in this context.

Hi,

In this context, I think a module is probably a .NET “project”.

 
HTH,
Ann

you seem as sure as I do about what a module is. maybe you can reach out to whomever crafted that message and ask them? Hopefully they can explain it and it makes sense.

@ganncamp - This is cropping up again. Here’s where I see the warnings, what the messages actually say, and the configuration settings are for the project.

I would really like to know what to do to resolve this warning.

Hi,

In fact, I’m not sure there’s anything you can do to resolve them. I’m referring this to the team for a deeper look.

 
Ann

Hello @StingyJack ,

Could you tell me if you have configured the property sonar.modules for your scanner execution? If positive, what is the value?

@Alexandre_Holzhey this repo is not using a sonar.properties file and I dont see where the sonarcloud UI allows this property to be defined.

1 Like

@StingyJack i see you are setting the following properties at project level:

  • sonar.coverage.exclusions
  • sonar.cpd.exclusions
  • sonar.exclusions

The first two contains patterns that are not relative, so you get the deprecation warning (see here about this deprecation).

For example, you told us that you have:

sonar.coverage.exclusions (Coverage exclusions) = *DataServiceExecutor.cs
sonar.cpd.exclusions (Duplication Exclusions) = *Base*.cs

To be compliant with the deprecation warning, could you please try change to:

sonar.coverage.exclusions (Coverage exclusions) = **/*DataServiceExecutor.cs
sonar.cpd.exclusions (Duplication Exclusions) = **/*Base*.cs

You already have this similar pattern configured for sonar.exclusions, which don’t raise the warning. You can check our documentation page about the patterns we support.

Regarding the modules, you can check them at the background tasks view, scanner context. You have a few entries for sonar.moduleKey and each one is a module. I am not aware about how modules work for CS, but i can get more information about this if you want.

Please let me know if that helps and/or if you have further questions.

2 Likes

That link says…

patterns defined at root-level should now be defined using root relative path

The paths to the files are relative to the repo root. The paths aren’t wildcarded. Why is being specific a problem and being deprecated?

And what is a module in this context? I’ve got no vb, js, or PowerShell that would be using something called modules.

This means you have below file patterns at your root folder and not at some subfolder, that is correct? Please note that a single * matches one or more characters, not folders.

*DataServiceExecutor.cs
*Base*.cs

This deprecation is quite old, so probably something changed at your project/configuration for that to start appearing. Did you took a look at the link i provided to you regarding this topic?

Which context? Did you had a look at the modules you currently have in your project, as i explained to you previously? They make sense to you?

A path like “c:\windows\system32\drivers\etc\hosts” is a string made up of characters. So if * replaces 0 or or more characters (not 1), I expect that something like *32*etc* will match it, as will globstar of **\system32\driv*\**\hosts or c:\windows\**\h*. What I suspect is that this actually means is…

* replaces 0 or more characters in a single file or single directory name
** replaces 0 or more levels of directories in a path

If that is so, then I can prefix the paths with **/ so they traverse directories. Easy enough but that still doesnt address the warning message…

Did you had a look at the modules you currently have in your project,

I dont know what you mean when you use the word “module”. Netfx and netcore use module to indicate a program or assembly thats loaded for reflection. Powershell has a container for commands called a module. NodeJS and JS has modules, VB has a Module type. I dont get what sonar is considering a module or how those paths would be module relative.

Yes, but this string is a representation of a file in a path, which could contain (or not) folders. The documentation says to use single asterisk to replaces 0 or more chars in a single file or directory name. A path can contain multiple directories, that is why there is the double asterisk, just to replace fodlers.

Apart from this clarification, did you tried my suggestion?

Regarding the module concept, let me get in touch with the .NET team to clarify this. I agree that it is confusing.

This is what that configuration page says
image
The documentation matches it. Those are not matching what the product is observed to be doing.

What is observed is

* replaces 0 or more characters in a single file or single directory name
** replaces 0 or more levels of directories in a path
(not using the ? for anything)

I dont know if the docs are correct and the product is incorrect or if its vice versa, but one of the two needs to be addressed.

Yes, I added the globstar prefix and it stopped the module warning.

1 Like

Thanks for your feedback. I will reach out documentation team to check this.

I am happy this fixed your issue.

A module for a .NET analysis is internally (Sonar concept) referring to a project, which is generated automatically by the build tool (only for .NET). You don’t control this behavior and that is why the warning was confusing. I will check if we can improve that.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.