Unable to update project name via sonar.projectName property

I have a project in our SonarQube instance. For some reason, I want to rename the project via sonar.projectName parameter.

In the document, sonar.projectName is describes that:

If not provided and there is already a name in the DB, it won’t be overwritten.
Analysis parameters

But I couldn’t rename the project via mvn sonar:sonar -Dsonar.projectName=newName.

In the source code, the sonar.projectName parameter is described that:

Optional name of the project, used only if the project does not exist yet.

Which is correct? Is it not possible to change the project name without recreating the project?

Our environment:

  • SonarQube Community 9.9.0 deployed from zip
  • SonarScanner for Maven (sonar-maven-plugin):


Those docs also say:

<name> for Maven projects

Is it possible that you provided -Dsonar.projectName once on the command line, and it was renamed until your next analysis? Because with a Maven analysis, your pom <name> value will be automatically passed at each analysis.

Maybe just update the <name> element in your POM?


Just to confirm, it sounds like when using the Sonar Scanner for Maven, there is no way to prevent it from ALWAYS updating the Project Name from the pom file’s “name” element? That is consistent with the behavior we are seeing. This is causing us a lot of grief. We use the Sonarqube API to pre-configure all of our Sonarqube projects so the project names match the project names in our SCM. Java Maven projects appear to be the only projects that keeps flipping the sonar project name after every run. It seems the only way we can stop this issue is to add custom logic in the build pipeline to always overwrite the pom file’s “name” element with the user friendly project name before every sonar scan. This behavior makes sense as a default value if the project doesn’t exist in Sonarqube, but when would you ever want it to constantly update the project name on every scan?


Welcome to the community!

To be fair, it’s not usually an update. :woman_shrugging:

Can I ask why you would want a different name in the pom than you actually want people to use as the project’s name?


Our applications/products have well formed names that are reflected in all of our business and developer tools (SCM, Sonarqube, Jira, etc.). Our new application automation uses the Sonarqube API to pre-configure the application’s project name, key, etc. to synch with all of those tools. Everything works great for all other tech stacks running sonarqube scans (.Net, React, Python, Go, etc.) as they do not override the project name that we have already set. Once we hand the application repository over to developers, we have no control over their changes to the pom file. When you have a development team with a mix of internal and external developers, it is very difficult to make them follow standards. We have not had the need to build extra logic to the devops process for creating new repositories to update the “name” field in the pom file to accommodate the issue. We would still have to implement logic to prevent developers from overwriting the values we default it to. The “name” in the pom doesn’t have any relevance since the jar file is named from the artifactid, and there is no pom file packaged with containerized applications that are deployed. If we were building publicly consumed software, it might be different.

We were able to workaround it for now, but the developers could still overwrite it. We default the pom file’s “name” element to “${env.CI_PROJECT_TITLE}”, which is the environment variable containing the SCM project title in our pipelines.

1 Like


Thanks for sharing your use case.

I’m glad you worked through this.


1 Like