SonarScanner for Maven (projectName)

SonarQube
1

Hi,

The documentation on SonarScanner for Maven and how it handles sonar properties with regarding to pom.xml is not really documented well enough.

I’ve read in the forum and can see that this has been up before, e.g. here.

The documentation needs to include (which I haven’t been able to find):

  1. information on what sonar properties are set and how it’s resolved as well as in what context it is set. e.g.

property set from context/branch
sonar.projectVersion pom.xml:project.version all branches
sonar.projectName pom.xml:project.name only main branch (note: main here in not “main” per se but main branch as per SonarQube)

  1. precedence of pom.xml, command line options and environment variables

It could be that I’ve missed this in the documentation but here are some questions nonetheless:

  1. Can one configure how SonarScanner determines sonar.projectName? It’s seems to be only <project.artifactId>? This is not always enough since it causes SonarQube projects with the same name for us. Would it be possible to have the option to configure if it should be:

a. <project.groupId>.<project.artifactId> or
b. <project.artifactId>
c. ???

  1. What is the precedence as per 2 above?
3

Hey there!

I agree that we could do something like this but for Maven. I’ll ping our Docs folks to see if that makes sense.

The logic is all contained in this rather noisy file:

Command line options always win.

You can’t configure what properties it picks up, but you can either set -Dsonar.projectName=newname as an analysis parameter, or add a <sonar.projectName> setting to your pom.xml

<properties>
  <sonar.projectName> [...] </sonar.projectName>
</properties>
5

Hi,

in addition to Colin’s answer.

The precedence of properties in Maven is:

  1. CLI parameters (-D flag) take the highest precedence
  2. Properties defined in the project’s POM file come next in order of precedence
  3. Properties defined in parent POMs follow
  4. Properties defined in settings.xml come after that

This means:

  • CLI properties (using -D flag) override all other property definitions
  • Properties defined in the child POM file override those in the parent POM
  • Properties in the active profile of a POM override those defined directly in the POM

@Colin The documentation for the Maven properties has changed between 9.9 LTS and latest

9.9 LTA

image
image815×435 34.1 KB

there’s an error, the default value for sonar.projectName is the artifactid from pom.

vs latest

image
image914×208 15.2 KB

image
image904×370 26.4 KB

The documentation for latest misses the default values.

Gilbert

6

@Colin @anon67236913 Thank you for the response.

  1. The priority order is as expected then :+1:t5:, but where is it documented?
  2. We used be on LTS but decided to go with latest recently because there were always new features that we wanted to use. Hence, the reason why we didn’t see the default values.
  3. Like I mentioned initially, it would be useful if one could select what should make up projectName (and not only artifactId).

Background:

Our team is firmly against configuration files unless they are really needed. We have so many configuration files in addition to sonar-project.properties.

I therefore developed a web service that handles our integration between SQ and GitLab. It basically allows us to run our git repos without a static sonar-project.properties file. The file is created on-the-fly by the web service

input: GitLab project ID

output:

a) sonar-project.properies values: projectKey and projectName (with a configurable selection for projectName as mentioned above we would no longer need to generate a projectName)
b) SonarQube badges: link or redirect image

7

They’re documented here, the very first section.

To be clear, the artifact ID only gets used if there’s no <name> tag in the pom.xml.

 <name>Shaker</name>

Do your pom.xml files not have this <name>?

10

@anon67236913 One more thing, one could argue that the information about how SonarQube uses information from Maven is mislocated. I personally think that it’s logical to have general information about analysis parameters under Analysis parameters and language/build specific information under Scanners. It’s natural when using, e.g. the SonarScanner for Maven to go to that section to find more information about how that scanner works.

Having detalied information about all scanners under Analysis parameters clutters that section and unless you EOL/deprecate (as with Ant) and remove scanners that section will only grow.

Ideally, I would like to have a standard matrix for all scanners detailing what data the scanner supports and if so, how it is mapped. The information for the different scanners all have different layout and information (e.g. Maven is a single page whereas NPM has several pages).

My 2 cents,
Jimisola

11

Thanks. Missed that completley. Was looking for a section title similar to Mandatory parameters.

Yes, we have project.name in our pom.xml. SonarQube is not our only tool though, I’m just not sure how it would affect our other tools if we change if from:

<name>${project.artifactId}</name>

to

<name>${project.groupId}.${project.artifactId}</name>

Will have to look into that. That’s why I was wondering if projectName source could be configurable.