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.
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?
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.
