You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I run the analysis I get messages like The class 'com.foo.Bar' could not be matched to its original source file. It might be a dynamically generated class..
The file is not dynamically generated.
It is generated, but by the build and at the time the analysis is run, it is present on the filesystem.
I thought the problem is, that it is in the gen-src folder and we configured in SQ to exclude gen-src/**, as we are not interested in issues found in generated code.
But even without the exclude it would not find the file, as the ByteCodeResourceLocator has a hard-coded list of possible source locations ("src/main/java","src/main/webapp","src/main/resources", "src", "src/java", "app", "src/main/scala").
Shouldn't this instead use what is configured via sonar.sources property and then also just with full-path, not with ends-with?
Currently the list could be reduced to "src", "app", due to the fix to #51 which introduced an ends-with check. Only due to that it also works for source sets where the code is in src/other/java and so on.
I think it would be much more accurate and reliable if you use the configured source directories and again an exact match algorithm without the ends-with fallback, as with that you could theoretically also find source files that are not related or whatever and that should not be part of the analysis.
You can get the configured list using org.sonar.api.batch.sensor.SensorContext#config().get("sonar.sources") for the currently analyzed module.
Environment
Component
Version
SonarQube
7.5
Sonar-FindBugs
3.9.2
Gradle
4.10.3
Java
11.0.1
The text was updated successfully, but these errors were encountered:
Issue Description
When I run the analysis I get messages like
The class 'com.foo.Bar' could not be matched to its original source file. It might be a dynamically generated class.
.The file is not dynamically generated.
It is generated, but by the build and at the time the analysis is run, it is present on the filesystem.
I thought the problem is, that it is in the
gen-src
folder and we configured in SQ to excludegen-src/**
, as we are not interested in issues found in generated code.But even without the exclude it would not find the file, as the
ByteCodeResourceLocator
has a hard-coded list of possible source locations ("src/main/java","src/main/webapp","src/main/resources", "src", "src/java", "app", "src/main/scala"
).Shouldn't this instead use what is configured via
sonar.sources
property and then also just with full-path, not with ends-with?Currently the list could be reduced to
"src", "app"
, due to the fix to #51 which introduced an ends-with check. Only due to that it also works for source sets where the code is insrc/other/java
and so on.I think it would be much more accurate and reliable if you use the configured source directories and again an exact match algorithm without the ends-with fallback, as with that you could theoretically also find source files that are not related or whatever and that should not be part of the analysis.
You can get the configured list using
org.sonar.api.batch.sensor.SensorContext#config().get("sonar.sources")
for the currently analyzed module.Environment
The text was updated successfully, but these errors were encountered: