Hi,
we have configured the java binaries path for the SonarScanner with wildcards:
sonar.java.binaries=projects/../plugins/../bin/..
This seems not to work (some rules work in SonarLint that do not work on SonarQube server). Could you please tell me if there is a possibility to include wildcards? (It seems to work for “sonar.sources”)
Greeting,
Holger
Info about versions:
Hi,
All the magic is happening in this class : https://github.com/SonarSource/sonar-java/blob/master/java-frontend/src/main/java/org/sonar/java/AbstractJavaClasspath.java
And more precisely in sonarjava.
Regarding wildcards those should be supported to some extent : but just to be clear are you talking about wildcards ( somepath/** ) or relative paths (foo/…/bar) ?
Hi,
I’d like to add some additional info: We have the following module/project structure
projects/{layer}/plugins/{module}
The {module} contains both src and bin folders. The property for the sources is configured as
sonar.sources=projects/../plugins/../src/..
All our sources are found and analyzed, so we assumed the property is configured correctly and used the same format for the binaries. However, the rules, that require binaries do not find anything, because the our own class files are not present during analysis.
When changing the sources property to sonar.sources=projects/**/plugins/**/src we’ve got a
java.nio.file.InvalidPathException: Illegal char <*> at index 9: projects/*/plugins/*/src. We assumed, the binaries property would cause the same exception.
Currently, we use the following settings:
sonar.sources=projects
sonar.java.binaries=projects/*/plugins/*/bin
This seems to work.
It appears that the directory paths for sonar.sources and sonar.java.binaries are handled differently, for one property wildcards are supported, for the other they are not.
Can you update the documentation to clarify which values are accepted for each property and how the paths are interpreted?
Hi @oliver,
Sorry for the delay.
Indeed, sonar.sources does not accept wildcards, it should be a list of directories (not files!) to analyze (may be not really explicit but it’s mentioned here). If you want to narrow a list of files to analyze you should use other properties like sonar.exclusions, which allow wildcards (see here).
And you are right, sonar.sources and sonar.java.binaries are handled differently. Yet I expect sonar.java.binaries to support the same syntaxes as described here.
Lastly, in case you didn’t know, there are scanners for maven and gradle available. These scanners automatically set sonar.java.binaries.
We are also seeing issues with sonarqube not finding classes. We run the gradle scanner and just keep getting the error:
No files nor directories matching ‘**/*.class’
Even though the .class files are there (in deep folders).