Why "Please, make sure your "sonar.junit.reportPaths" property is configured properly"?

SonarScanner for Gradle versions and
Gradle 8.7

I’m getting six warnings like the following in my logs every time I run gradlew build sonar:

Resource not found: com.mypackage.MyTest under the directory C:\MyDir\my-project\my-subproject while reading test reports.
Please, make sure your "sonar.junit.reportPaths" property is configured properly

The warnings are always for the same six tests. Some are in Java, and some Kotlin. I have over 100K unit tests spread across over 380 modules, so it’s odd that I’m only getting six such warnings if the build is truly misconfigured. I don’t see anything special about the ones being reported, or the subprojects they’re in. I don’t get warnings for other tests in the same subproject.

The only settings I have configured are in my root ‘build.gradle.kts’:

sonar {
    properties {
        property("sonar.projectKey", "MyProject")
        property("sonar.host.url", "https://sonarqube.myserver.me.com")
        property("sonar.verbose", true)

I have no other sonar configuration under subprojects or in any subproject ‘build.gradle.kts’ files.

The docs say the default for sonar.junit.reportPaths is:

${test.testResultsDir} (if the directory exists)

Is that meant to read ${project.testResultsDir} or {project.java.testResultsDir}? I don’t see any such property in the Gradle DSL or API for that would correspond to “${test.testResultsDir}”.

If so, mine is the default, and when I look there I see a ‘my-subproject/build/test-results/test/TEST-com.mypackage.MyTest.xml’ file that corresponds to the printed warning, along with several other XML test result files for other tests in the same subproject for which no warnings were logged. I have a corresponding ‘my-subproject/src/test/java/com/mypackage/MyTest.java’ and a ‘my-subproject/build/classes/java/test/com/mypackage/MyTest.class’ file as well.

What “resource” is SonarScanner looking for in connection to this warning?


Could you provide the full analysis log?


Hi Ann,

What specifically do you mean by “full analysis log”?

I found this post on locating analysis logs: How to find logs about importing code coverage. If I run gradlew --debug build sonar > build.out with sonar.verbose=true I get an over 4GB log file, which I wouldn’t practically be able to redact…


   Debug level logging will leak security sensitive information!

   For more details, please refer to https://docs.gradle.org/8.7/userguide/logging.html#sec:debug_security in the Gradle documentation.

If you can guide me to specific log lines to search for, I could post those. Here are all the matches for one of the six tests in question:

Line 7629705: 2024-05-02T18:17:34.322-0700 [DEBUG] [org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor] Executing test class com.mypackage.MyTest
Line 7629975: 2024-05-02T18:17:35.256-0700 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Generate HTML test report for MyTest' started
Line 7629976: 2024-05-02T18:17:35.267-0700 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Completing Build operation 'Generate HTML test report for MyTest'
Line 7629977: 2024-05-02T18:17:35.267-0700 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Generate HTML test report for MyTest' completed
Line 7630018: 2024-05-02T18:17:34.864-0700 [DEBUG] [TestEventLogger] MyTest STARTED
Line 7630020: 2024-05-02T18:17:34.907-0700 [DEBUG] [TestEventLogger] MyTest > my test method() STARTED
Line 7630023: 2024-05-02T18:17:35.005-0700 [DEBUG] [TestEventLogger] MyTest > my test method() PASSED
Line 7630025: 2024-05-02T18:17:35.007-0700 [DEBUG] [TestEventLogger] MyTest PASSED
Line 7778042: 2024-05-02T19:17:41.514-0700 [DEBUG] [org.sonarqube.gradle.SonarTask] Class not found in resource cache : com.mypackage.MyTest
Line 7778043: 2024-05-02T19:17:41.514-0700 [DEBUG] [org.sonarqube.gradle.SonarTask] Class not found in resource cache : com.mypackage.MyTest
Line 7778044: 2024-05-02T19:17:41.514-0700 [DEBUG] [org.sonarqube.gradle.SonarTask] Resource not found: com.mypackage.MyTest
Line 7778101: 2024-05-02T19:17:54.994-0700 [INFO] [org.sonarqube.gradle.SonarTask] Searching for com/mypackage/MyTest
Line 7778102: 2024-05-02T19:17:54.994-0700 [WARN] [org.sonarqube.gradle.SonarTask] Resource not found: com.mypackage.MyTest under the directory C:\MyDir\my-project\my-subproject while reading test reports. Please, make sure your "sonar.junit.reportPaths" property is configured properly


Yeah… It’s pretty bad. Ideally you’ll post a --info log that starts with the analysis command.


Hello @ianbrandt,

This error tells you that in the directory C:\MyDir\my-project\my-subproject the file com.mypackage.MyTest was not found.

This could happen due to various reasons. The most probable one is that your class com.mypackage.MyTest is not located under the directory com/mypackage/. This often happens with Kotlin classes.

Let me know if this is the case for you.


Hi Margarita,

May I ask you to be a bit more specific here? I wouldn’t expect to literally have a C:\MyDir\my-project\my-subproject\com.mypackage.MyTest file.

Do you mean a com\mypackage\MyTest.java or com\mypackage\MyTest.kt file anywhere under C:\MyDir\my-project\my-subproject (e.g. at C:\MyDir\my-project\my-subproject\src\test\java\com\mypackage\MyTest.java or C:\MyDir\my-project\my-subproject\src\test\kotlin\com\mypackage\MyTest.kt)? Or is it looking for a com\mypackage\MyTest.class file anywhere under C:\MyDir\my-project\my-subproject (e.g. C:\MyDir\my-project\my-subproject\build\classes\java\test\com\mypackage\MyTest.class or C:\MyDir\my-project\my-subproject\build\classes\kotlin\test\com\mypackage\MyTest.class)?

One of the six errors I’m getting is for a class that’s in a Kotlin source file not of the same name (because there’s multiple classes in the file, but then that’s supported by Kotlin, and so shouldn’t it be by SonarScanner?), but the other five are a mix of Java and Kotlin tests that seem to have corresponding source and class files in the standard places, and their subdirectories and .java/.kt/.class file names all align with their packages and class names.

1 Like

An update, I extracted that one Kotlin test to its own file of the same name and rescanned. That error dropped off. Then upon closer inspection I realized two of the other error cases were Kotlin tests in files with slightly different names from their class names. I adjusted the file names, and those two errors dropped off as well.

I do think SonarScanner should support Kotlin test classes where the filename doesn’t match, as that’s not a requirement with Kotlin. I can certainly live with these changes for now, but I can see this issue cropping up again in the future.

Now I’m just left with errors for three Java tests. I’ve triple checked them, and their class names and package names definitely align with their file names and folders. They’re plain old JUnit 5 tests in the src\test\java folders of their corresponding projects. Two happen to be in the same subproject, but the other is in an unrelated project. The classes all had default access. I changed them to public class and rescanned, but that made no difference. I do have other Java unit tests in the overall project that aren’t resulting in these errors. I simply can’t see anything different or out of the ordinary with these three.

I did capture a --info level build log, and it’s only 20KB vs. the 4GB for the --debug log. There is still more project information in it than I can share publicly, so to post more I’d need to be pointed towards particular sections of interest that I could extract and redact.

1 Like

Thanks for the update @ianbrandt,

I agree that Kotlin’s behavior should be improved and I created a ticket for it:


At least you have a workaround for Kotlin, so let’s now focus on Java.

As for Java, the problem that we have in Kotlin shouldn’t occur here. So it looks like the problem is different. If your debug log is too big to share, probably, I only need you to answer this question:

  • Have you seen such messages in your Debug log: “Class not found in resource cache : $className”?

Another thing that we can look at to debug the issue is to run the sonar task as ./gradlew sonar -Dsonar.scanner.dumpToFile=out.properties and share the content of out.properties with me(you can remove all sensitive data) or if not sure, ping me to open a private conversation.

The best variant is if you could provide a small reproducer that you can easily share.


Hi @Margarita_Nedzelska,

Thank you for creating the ticket for the Kotlin handling.

I just generated a new --debug log, and searching it I have 1475 hits for “Class not found in resource cache”. Many seem to be repeats for the same class, e.g.:

Line 7934053: 2024-05-13T09:23:03.318-0700 [DEBUG] [org.sonarqube.gradle.SonarTask] Class not found in resource cache : com.mypackage.SomeTest
Line 7934054: 2024-05-13T09:23:03.318-0700 [DEBUG] [org.sonarqube.gradle.SonarTask] Class not found in resource cache : com.mypackage.SomeTest
Line 7934055: 2024-05-13T09:23:03.318-0700 [DEBUG] [org.sonarqube.gradle.SonarTask] Class not found in resource cache : com.mypackage.SomeTest

None of them are for any of the three Java tests still triggering the “Resource not found” warnings, though. I searched on all three test class names, and the only log lines about them are each as follows:

Line 7911469: 2024-05-13T09:13:37.495-0700 [DEBUG] [org.sonarqube.gradle.SonarTask] 'my-subproject\src\test\java\com\mypackage\MyTest.java' indexed as test with language 'java'
Line 8034090: 2024-05-13T10:59:26.854-0700 [DEBUG] [org.sonarqube.gradle.SonarTask] 'my-subproject/src/test/java/com/mypakcage/MyTest.java' generated metadata as test  with charset 'ISO-8859-1'
Line 8034232: 2024-05-13T10:59:37.852-0700 [INFO] [org.sonarqube.gradle.SonarTask] Searching for java/com/mypakcage/MyTest
Line 8034233: 2024-05-13T10:59:37.852-0700 [WARN] [org.sonarqube.gradle.SonarTask] Resource not found: com.mypackage.MyTest under the directory C:\Dev\Repos\my-project\my-subproject while reading test reports. Please, make sure your "sonar.junit.reportPaths" property is configured properly

I’ll get you the scanner properties shortly.

Thanks for the update. From the logs, I can see that this class wasn’t located properly by our ResourceLocator. This is needed to be able to report metrics on the files. It doesn’t affect the analysis itself.

To investigate this further I indeed need the properties dump. It looks like the problem might be because of the module where the class is and where the report is. SO waiting for your reply.

It would also speed up an investigation if you could provide a small example project-reproducer, where I can reproduce the issue by myself and debug it.


Hi Margarita,

I set -Dsonar.scanner.dumpToFile=out.properties first via the command line, and then via the sonar.properties block in my root ‘build.gradle.kts’, but every time I ran gradlew build sonar the build completed abnormally quickly, and I didn’t see an ‘out.properties’ file.

After several attempts thinking I must be doing something wrong, or was dealing with some Gradle cache invalidation issue, I finally turned on --info. Then I saw that file isn’t dumped to the project root directory or present working directory, but to your ‘$GRADLE_USER_HOME\daemon\$GRADLE_VERSION’ directory:

Simulation mode. Configuration written to C:\Dev\.gradle\daemon\8.7\out.properties

That log line explains a lot, namely why the sonar task was completing so quickly, and that the file was actually being written out, just to an unexpected location. It would be helpful if instead of at INFO level, that was logged at LIFECYCLE or QUIET level. It would also help if there was a note in the docs about the dump file going to your $GRADLE_USER_HOME\daemon dir.

The file has more project details in it than I can share publicly, but I could send it to you directly. I don’t see a way to initiate a direct message here in the forums, but perhaps you can on your end.

Alternatively, based on the “Show SonarScanner Context” note in the docs, I copied the properties from my server. The format there is more readable than the dumpToFille format, so I was able to produce this redacted subset that includes the two modules with the three problematic tests:

Bundled analyzers:
  - Clean as You Code (cayc)
  - IaC Code Quality and Security (iac)
  - PL/SQL Code Quality and Security (plsql)
  - Scala Code Quality and Security (sonarscala)
  - C# Code Quality and Security (csharp)
  - Vulnerability Analysis (security)
  - Java Code Quality and Security (java)
  - HTML Code Quality and Security (web)
  - Flex Code Quality and Security (flex)
  - XML Code Quality and Security (xml)
  - Text Code Quality and Security (text)
  - VB.NET Code Quality and Security (vbnet)
  - Swift Code Quality and Security (swift)
  - CFamily Code Quality and Security (cpp)
  - Python Code Quality and Security (python)
  - Dataflow Bug Detection Rules for Python (dbdpythonfrontend)
  - Dataflow Bug Detection (dbd)
  - Go Code Quality and Security (go)
  - JaCoCo (jacoco)
  - Kotlin Code Quality and Security (kotlin)
  - Dataflow Bug Detection Rules for Java (dbdjavafrontend)
  - T-SQL Code Quality and Security (tsql)
  - JavaScript/TypeScript/CSS Code Quality and Security (javascript)
  - Ruby Code Quality and Security (ruby)
  - Vulnerability Rules for C# (securitycsharpfrontend)
  - Vulnerability Rules for Java (securityjavafrontend)
  - Vulnerability Rules for JS (securityjsfrontend)
  - Vulnerability Rules for Python (securitypythonfrontend)
  - PHP Code Quality and Security (php)
  - ABAP Code Quality and Security (abap)
  - Configuration detection for Code Quality and Security (config)
  - Vulnerability Rules for PHP (securityphpfrontend)
Global server settings:
  - sonar.core.id=The-ID
  - sonar.core.serverBaseURL=https://sonarqube.my.tld
  - sonar.core.startTime=2024-02-01T08:21:22+0000
  - sonar.dbcleaner.branchesToKeepWhenInactive=master,develop,trunk
  - sonar.forceAuthentication=true
  - sonar.plugins.risk.consent=ACCEPTED
  - sonar.qualityProfiles.allowDisableInheritedRules=false
Project server settings:
Project scanner properties:
  - sonar.gradle.skipCompile=true
  - sonar.host.url=https://sonarqube.my.tld
  - sonar.kotlin.gradleProjectRoot=C:\Dev\Repos\my-project
  - sonar.modules=:my-top-level-module-1,:my-top-level-module-2,...,:my-top-level-module-N
  - sonar.projectBaseDir=C:\Dev\Repos\my-project
  - sonar.projectKey=My_Project_Key
  - sonar.projectName=my-project
  - sonar.projectVersion=16851-0.SNAPSHOT
  - sonar.scanner.app=ScannerGradle
  - sonar.scanner.appVersion= 8.7
  - sonar.sourceEncoding=iso-8859-1
  - sonar.sources=C:\Dev\Repos\my-project\build.gradle.kts,C:\Dev\Repos\my-project\my-subproject\build.gradle.kts,...
  - sonar.verbose=true
  - sonar.working.directory=C:\Dev\Repos\my-project\build\sonar
Scanner properties of module: My_Project_Key:my-top-level-module-1:my-submodule-1
  - sonar.binaries=C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\classes\java\main,C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\classes\kotlin\main
  - sonar.coverage.jacoco.xmlReportPaths=C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\reports\jacoco\test\jacocoTestReport.xml
  - sonar.jacoco.reportPath=C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\jacoco\test.exec
  - sonar.jacoco.reportPaths=C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\jacoco\test.exec
  - sonar.java.binaries=C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\classes\java\main,C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\classes\kotlin\main
  - sonar.java.enablePreview=false
  - sonar.java.jdkHome=C:\Dev\.jdks\temurin-11.0.23
  - sonar.java.libraries=C:\Dev\Repos\my-project\my-other-top-level-project\my-other-subproject\build\libs\my-other-top-level-project.my-other-subproject.jar,C:\Dev\.gradle\caches\modules-2\files-2.1\org.jetbrains.kotlin\kotlin-stdlib\1.9.23\dbaadea1f5e68f790d242a91a38355a83ec38747\kotlin-stdlib-1.9.23.jar,...
  - sonar.java.source=11
  - sonar.java.target=11
  - sonar.java.test.binaries=C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\classes\java\test,C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\classes\kotlin\test
  - sonar.java.test.libraries=C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\classes\java\main,C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\classes\kotlin\main,C:\Dev\Repos\my-project\my-other-top-level-project\my-other-subproject\build\libs\my-other-top-level-project.my-other-subproject.jar,C:\Dev\.gradle\caches\modules-2\files-2.1\org.jetbrains.kotlin\kotlin-stdlib\1.9.23\dbaadea1f5e68f790d242a91a38355a83ec38747\kotlin-stdlib-1.9.23.jar,...
  - sonar.junit.reportPaths=C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\test-results\test
  - sonar.junit.reportsPath=C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\test-results\test
  - sonar.libraries=C:\Dev\Repos\my-project\my-other-top-level-project\my-other-subproject\build\libs\my-other-top-level-project.my-other-subproject.jar,C:\Dev\.gradle\caches\modules-2\files-2.1\org.jetbrains.kotlin\kotlin-stdlib\1.9.23\dbaadea1f5e68f790d242a91a38355a83ec38747\kotlin-stdlib-1.9.23.jar,...
  - sonar.moduleKey=My_Project_Key:my-top-level-module-1:my-submodule-1
  - sonar.projectBaseDir=C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1
  - sonar.projectDescription=My Submodule 1 in My Top-level Module 1
  - sonar.projectKey=My_Project_Key:my-top-level-module-1:my-submodule-1
  - sonar.projectName=my-submodule-1
  - sonar.projectVersion=16851-0.SNAPSHOT
  - sonar.sourceEncoding=iso-8859-1
  - sonar.sources=C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\src\main\java,C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\src\main\kotlin
  - sonar.surefire.reportsPath=C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\build\test-results\test
  - sonar.tests=C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\src\test\java,C:\Dev\Repos\my-project\my-top-level-module-1\my-submodule-1\src\test\kotlin
Scanner properties of module: My_Project_Key:my-top-level-module-2:my-submodule-2:my-sub-submodule
  - sonar.binaries=C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\build\classes\kotlin\main
  - sonar.coverage.jacoco.xmlReportPaths=C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\build\reports\jacoco\test\jacocoTestReport.xml
  - sonar.jacoco.reportPath=C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\build\jacoco\test.exec
  - sonar.jacoco.reportPaths=C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\build\jacoco\test.exec
  - sonar.java.binaries=C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\build\classes\kotlin\main
  - sonar.java.enablePreview=false
  - sonar.java.jdkHome=C:\Dev\.jdks\temurin-11.0.23
  - sonar.java.libraries=C:\Dev\Repos\my-project\my-other-top-level-project\my-other-subproject\build\libs\my-other-top-level-project.my-other-subproject.jar,C:\Dev\.gradle\caches\modules-2\files-2.1\org.jetbrains.kotlin\kotlin-stdlib\1.9.23\dbaadea1f5e68f790d242a91a38355a83ec38747\kotlin-stdlib-1.9.23.jar,...
  - sonar.java.source=11
  - sonar.java.target=11
  - sonar.java.test.binaries=C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\build\classes\java\test,C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\build\classes\kotlin\test
  - sonar.java.test.libraries=C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\build\classes\kotlin\main,C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\build\classes\kotlin\testFixtures,C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\build\libs\my-top-level-module-2.my-submodule-2.my-sub-submodule.jar,C:\Dev\Repos\my-project\my-other-top-level-project\my-other-subproject\build\libs\my-other-top-level-project.my-other-subproject.jar,...,C:\Dev\Repos\my-project\my-other-top-level-project\my-other-subproject\build\classes\kotlin\testFixtures,...
  - sonar.junit.reportPaths=C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\build\test-results\test
  - sonar.junit.reportsPath=C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\build\test-results\test
  - sonar.libraries=C:\Dev\Repos\my-project\my-other-top-level-project\my-other-subproject\build\libs\my-other-top-level-project.my-other-subproject.jar,C:\Dev\.gradle\caches\modules-2\files-2.1\org.jetbrains.kotlin\kotlin-stdlib\1.9.23\dbaadea1f5e68f790d242a91a38355a83ec38747\kotlin-stdlib-1.9.23.jar,...
  - sonar.moduleKey=My_Project_Key:my-top-level-module-2:my-submodule-2:my-sub-submodule
  - sonar.projectBaseDir=C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule
  - sonar.projectDescription=My Sub-submodule in My Submodule 2 in My Top-level Module 2
  - sonar.projectKey=My_Project_Key:my-top-level-module-2:my-submodule-2:my-sub-submodule
  - sonar.projectName=my-sub-submodule
  - sonar.projectVersion=16851-0.SNAPSHOT
  - sonar.sourceEncoding=iso-8859-1
  - sonar.sources=C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\src\main\kotlin
  - sonar.surefire.reportsPath=C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\build\test-results\test
  - sonar.tests=C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\src\test\java,C:\Dev\Repos\my-project\my-top-level-module-2\my-submodule-2\my-sub-submodule\src\test\kotlin

Regarding a reproducer, I can’t see anything unusual about these three tests. There are other tests in similar modules that aren’t resulting in any warnings. As such, I wouldn’t know where to begin to create a minimal project that has a chance of demonstrating the issue.

A quick update, I think I may have a lead on the problem. I used a PowerShell script to do a recursive search, and the two modules in question here are the only two out of the ~400 in my project that have both src\test\java and src\test\kotlin tests at the same time. Perhaps the ResourceLocator doesn’t currently handle that situation.

I just added a new src\test\java test to a module that only had src\test\kotlin tests and kicked off another scan. I’ll report back on whether this new Java test results in an additional “Resource not found” warning.


False alarm. The added Java test did show up as a new warning, but then I removed all Kotlin tests from that same module, cleaned, and rescanned. The Java test still resulted in a “Resource not found” warning.

I ran a few more experiments, and that lead me to realize that we previously migrated almost all of our Java tests to a separate src/legacyTest suite that we aren’t scanning with sonar. We don’t mandate that new tests be written in Kotlin, so I was assuming we’d have more than just three Java tests in the default src/test suite across all our modules, but we don’t.

Now that I see any Java test in our src/test suite produces the “Resource not found” warning, that gives me a basis for attempting a reproducer. I’ll give that a go and report back.

1 Like