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
I have a project that is analyzed with SonarQube 9.9.
As the “Dependency-Check Integration” plugin’s scanner is reporting the findings on the build scripts, I added the build scripts as source files for the analyzed project.
I just ported it from Groovy DSL build scripts to Kotlin DSL build scripts (which are not named build.gradle.kts, but <project-name>.gradle.kts).
For the subprojects where also other sources are available, this works.
But in the root project only the build script is in the SonarQube sources.
As there is no other code, there is also no sonar.java.binaries set.
If I now run the SonarQube analysis, I get:
Can not execute Findbugs
[...]
Caused by: java.lang.IllegalStateException: One (sub)project contains Java source files that are not compiled (/var/lib/teamcity-buildAgent/work/aed74103c764f0f2).
Property sonar.java.binaries was not set, it is required to locate the compiled .class files. For instance set the property to: sonar.java.binaries=target/classes
The error message is actually wrong.
There is no Java source file, the build script is the only source in that module.
And a .kts file typically is of course not compiled and thus no binaries available.
If there are only .kts files in the source (or maybe at least if there are only .gradle.kts files), the FindBugs scanner should probably not get invoked and complain about missing class files.
Not adding the Kotlin DSL Gradle build script or excluding it fixes that problem that makes the analysis fail. But that is of course a sub-optimal solution as then the file is not available as source for other scanners and also not available in the web ui.
Environment
Component
Version
SonarQube
9.9
Sonar-FindBugs
4.2.7
Gradle
7.6.4
Java
17
The text was updated successfully, but these errors were encountered:
Thank you for reporting the issue!
Would it make sense to ignore .kts files when checking if the project has sources but no compiled code?
In other words: if the project has .kts sources but no compiled .class file it should be fine (nothing for SpotBugs to analyse)
Issue Description
I have a project that is analyzed with SonarQube 9.9.
As the “Dependency-Check Integration” plugin’s scanner is reporting the findings on the build scripts, I added the build scripts as source files for the analyzed project.
I just ported it from Groovy DSL build scripts to Kotlin DSL build scripts (which are not named
build.gradle.kts
, but<project-name>.gradle.kts
).For the subprojects where also other sources are available, this works.
But in the root project only the build script is in the SonarQube sources.
As there is no other code, there is also no
sonar.java.binaries
set.If I now run the SonarQube analysis, I get:
The error message is actually wrong.
There is no Java source file, the build script is the only source in that module.
And a
.kts
file typically is of course not compiled and thus no binaries available.If there are only
.kts
files in the source (or maybe at least if there are only.gradle.kts
files), the FindBugs scanner should probably not get invoked and complain about missing class files.Not adding the Kotlin DSL Gradle build script or excluding it fixes that problem that makes the analysis fail. But that is of course a sub-optimal solution as then the file is not available as source for other scanners and also not available in the web ui.
Environment
The text was updated successfully, but these errors were encountered: