File path 400 character limit

Must-share information (formatted with Markdown):

  • (SonarQube, Scanner, Plugin, and any relevant extension)
  • Docker

Hello everyone, I have used Sonarqube before, which is a great tool that helps me identify and solve many coding problems. However, due to some reasons, I haven’t used it for a while. Recently, I tried to use it again. After using Docker to build version 10.4, I scanned the code using Gitlab ci. However, I encountered an issue with a multi module project for Maven, Nested a lot (as a dependency library), when I scanned this project, it prompted me that the name of a certain project file exceeded the preset 400 character length limit. This was not encountered before when I used Sonarqube. Later, I checked community support and found that due to database field length limitations, Sonrqube can only store data up to 400 words long. I think this limitation is somewhat unreasonable, Can we consider using hash values as an alternative? I should be able to solve this problem, thank you

Or can you tell me what is the last stable version without this restriction?Thanks.

By the way, the current LTS version (9.9) does not have this issue and all work is running well. I hope the new version can solve this problem as soon as possible. To be honest, I really like the new UI, hahaha


Welcome to the community!

Are you saying that if you run exactly the same analysis against 9.9 and 10.4.1, the 9.9 analysis succeeds and the 10.4.1 analysis fails?

If so, can we have the logs from both analyses?

The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.

This guide will help you find them.


[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin: (default-cli) on project xxxxxxxxx: Component key ( length (403) is longer than the maximum authorized (400) → [Help 1]

I used gitlab ci, which is the error he encountered. In version 9.9, projectKey was passed through the mvn command, while in version 10.4, it was passed through the pom file attribute of Maven. Therefore, in 10.4, if it is a multi-module project, there will be a problem of duplicate keys. Through the community, I used the moduleKey attribute to mark different modules, but the problem of names exceeding the limit still exists


Thanks for the error line, but I was looking for full analysis logs.

Do you mean on the mvn command line with -Dsonar.projectKey?

What happens if you go back to what you were doing with 9.9?


Firstly, all the commands I used came from the boot page after Sonarqube introduced the Gitlab project. In 9.9, Sonarqube did not add the properties attribute of projectKey in the pom file, but instead provided this attribute in the Gitlab ciyml mvn - s. m2/settings.xml verify Sonar: Sonar - Dsonar. projectKey=xxxx. In 10.4, by adding the properties attribute of projectKey in the pom file, there is no additional - Dsonar.projectKey parameter in gitlab ciyml. All commands come from the Sonarqube project creation guide. In order to control variables, I used a unified Docker image as the runner (Maven: 3 eclipse temurin-17). As for the complete logs, since I have migrated to 9.9, only the error logs in GitLab are available. I have intercepted the error section, and the rest are normal Maven

I have discovered and exposed this issue by official personnel in the community, and the reason is also clear. It is because the default generated projectKey is too long, and in projects with multiple nested modules, the file name path is too long. Adding the two to identify a file exceeds the limit set by sonarqube. However, in 9.9, the default generated projectKey is shorter, so this problem did not occur (since this problem was not encountered before, it is uncertain whether earlier versions have this limit). I hope that the official can discover and increase the priority of solving this problem, as this restriction cannot be proactively lifted by the client. If it is necessary to adjust the project structure to adapt, I think it is unreasonable.

No offense, thank you for all the work you have done, providing convenient and fast tools for many people.


With my questions, I’m trying to determine:

  • The root cause: did the server change (I’m skeptical), the scanner behavior, or did your change in scanner invocation uncover something that was there before?
  • Is there a valid workaround?

So again:


I first used 10.4 and then went back to 9.9, both using the same ci image and mvn command. However, 10.4 encountered an issue with excessively long paths. To test this issue, I only need to build a Maven project that contains a single file and use overly long package names internally to wrap a file


For both analyses did you use

  • the same version of Maven
  • the same version of SonarScanner for Maven