SonarQube for IntelliJ locks dependency jar files

Environment:

  • Java: Eclipse Adoptium jdk-21.0.5.11-hotspot
  • OS: Windows 10 Enterprise
  • IDE: IntelliJ IDEA 2024.3.1.1 (Community Edition)
  • SonarQube for IDE (Intellij): 10.14.1.80220
  • SonarQube Server: Community Edition Version 9.9.1 (build 69595)
  • Node.js: 23.6.0
  • Maven: 3.9.9

When using the SonarLint plugin in IntelliJ, the Java process org.sonarsource.sonarlint.core.backend.cli.SonarLintServerCli does not terminate after performing an analysis and keeps a handle on many jar files used as dependencies in the (maven) project. This results in locked JAR files, preventing them from being overwritten during development. The issue persists until the process is manually killed.

Steps to Reproduce

  • Create a Maven project with the following pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>test</groupId>
    <artifactId>test-sonar</artifactId>
    <version>1.0.0-SNAPSHOT</version>
	<dependencies>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>33.4.0-jre</version>
        </dependency>
        <dependency>
            <groupId>org.jetbrains.kotlin</groupId>
            <artifactId>kotlin-runtime</artifactId>
            <version>1.2.71</version>
        </dependency>
	</dependencies>
</project>
  • Create a dummy Kotlin class:
package test

class AKotlinClass {
}
  • Configure a connection to a SonarQube Server.
  • Bind the project to the SonarQube Server.
  • Run an analysis with SonarQube for IDE.
  • Wait for the analysis to complete.

At this point the the files “kotlin-runtime-1.2.71.jar” and “guava-33.4.0-jre.jar” are locked. Trying to delete them from the Maven’s local repository (default location should be: %USERPROFILE%.m2\repo) will fail.
LockHunter shows that the Java process org.sonarsource.sonarlint.core.backend.cli.SonarLintServerCli owns the files (as well as some other transitive dependencies):