Error when running sonar task with Gradle 9.0.0-rc-1

SonarQube Server / Community Build
, ,
1

Currently we prepare the migration to Gradle 9. Our whole Android project build and pipeline is working so far. But we get the following error when running sonar Gradle task:

[2025-07-03T14:42:18.387Z] > Task :sonar FAILED
[2025-07-03T14:42:18.387Z] 
[2025-07-03T14:42:18.387Z] FAILURE: Build failed with an exception.
[2025-07-03T14:42:18.387Z] 
[2025-07-03T14:42:18.387Z] * What went wrong:
[2025-07-03T14:42:18.387Z] Execution failed for task ':sonar'.
[2025-07-03T14:42:18.387Z] > Resolution of the configuration ':app:debugCompileClasspath' was attempted without an exclusive lock. This is unsafe and not allowed.
[2025-07-03T14:42:18.387Z] 
[2025-07-03T14:42:18.387Z] * Try:
[2025-07-03T14:42:18.387Z] > For more information, please refer to https://docs.gradle.org/9.0.0-rc-1/userguide/viewing_debugging_dependencies.html.html#sub:resolving-unsafe-configuration-resolution-errors in the Gradle documentation.
[2025-07-03T14:42:18.387Z] > Run with --stacktrace option to get the stack trace.
[2025-07-03T14:42:18.387Z] > Run with --info or --debug option to get more log output.
[2025-07-03T14:42:18.387Z] > Run with --scan to generate a Build Scan (Powered by Develocity).
[2025-07-03T14:42:18.387Z] > Get more help at https://help.gradle.org.
[2025-07-03T14:42:18.387Z] 
[2025-07-03T14:42:18.387Z] BUILD FAILED in 5s

We are using sonar plugin version 6.2.0.5505.

With Gradle 8.14.2 everthing is working.

Would be nice if you could verify that and make sure we are not blocked when Gradle 9 hits final.

5 Likes
4

Hi @G00fY2,

Thank you for reporting this issue. Could you share how you invoke the :sonar task? On its own? With another task?

That would help us narrow down how the issue is triggered?

Thanks,

Dorian

6

Hi @Dorian_Burihabwa,

thanks for your reply. We have a dedicated step in our pipeline which simply executes:

sh “./gradlew sonar”

In general we use Sonarqube in an mixed Android and Kotlin-only multimodule project. There is no special configuration or logic involved.

The tasks succeeds with latest stable Gradle 8.14.3.

I can try to provide a reproducable project. But I thought you might have some test projects where you can check Gradle 9.0.0-rc-1 aswell and see if you run into the same issue.

Edit: Okay I saw there is work going on.
SCANGRADLE-234 Add Gradle 9.0.0-rc-1 to ITs

As a workaround adding --no-parallel seems to fix the issue (was suggested here).

7

Hey @G00fY2,

I can try to provide a reproducable project.

We would really appreciate if you could share such a project :folded_hands: .

Because a lot of our tests tend to run on code that was frozen a while ago (to detect regressions), we sometimes miss more modern use cases.

Cheers,

Dorian

9

Hi @Dorian_Burihabwa,

maybe I find time to set up sonar plugin inside an existing open source project like GitHub - android/nowinandroid: A fully functional Android app built entirely with Kotlin and Jetpack Compose.

But I also saw that you are already able to reproduce this error in your integrations tests, right?

10

We updated to 9.0.0-rc-3. There were some changes done to support parallel execution:

Still the sonar tasks only succeeds when adding “–no-parallel”. New error message without this is:

> Task :sonar FAILED
1 problem was found storing the configuration cache.
- Task `:sonar` of type `org.sonarqube.gradle.SonarTask`: error writing value of type 'org.gradle.api.internal.provider.DefaultMapProperty'

Edit: Nevermind, rerun the pipeline with --stacktrace flag and still get the same error message as 9.0.0-rc-1:

[2025-07-18T09:09:40.263Z] org.gradle.api.tasks.TaskExecutionException: Execution failed for task ‘:sonar’.
[2025-07-18T09:09:40.263Z] at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:38)
[2025-07-18T09:09:40.263Z] at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
[2025-07-18T09:09:40.264Z] at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
[2025-07-18T09:09:40.264Z] at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
[2025-07-18T09:09:40.264Z] at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:209)
[2025-07-18T09:09:40.264Z] at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204)
[2025-07-18T09:09:40.264Z] at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
[2025-07-18T09:09:40.264Z] at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
[2025-07-18T09:09:40.264Z] at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:166)
[2025-07-18T09:09:40.264Z] at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
[2025-07-18T09:09:40.264Z] at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
[2025-07-18T09:09:40.264Z] at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
[2025-07-18T09:09:40.264Z] at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:45)
[2025-07-18T09:09:40.264Z] at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:347)
[2025-07-18T09:09:40.265Z] at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:334)
[2025-07-18T09:09:40.265Z] at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.lambda$execute$0(DefaultTaskExecutionGraph.java:330)
[2025-07-18T09:09:40.265Z] at org.gradle.internal.operations.CurrentBuildOperationRef.with(CurrentBuildOperationRef.java:84)
[2025-07-18T09:09:40.265Z] at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:330)
[2025-07-18T09:09:40.265Z] at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:319)
[2025-07-18T09:09:40.265Z] at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:459)
[2025-07-18T09:09:40.265Z] at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:376)
[2025-07-18T09:09:40.265Z] at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
[2025-07-18T09:09:40.265Z] at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47)
[2025-07-18T09:09:40.265Z] Caused by: org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$IllegalResolutionException: Resolution of the configuration ‘:app:googleDevDebugCompileClasspath’ was attempted without an exclusive lock. This is unsafe and not allowed.

11

It seems I opened a duplicate for this.
I did some digging in the code of the gradle plugin and I think I found the issue.

Any multi-module gradle project will exhibit this problem, as far as I’m aware.

12

Hey @G00fY2

I am able to move past this issue as long as the following two configurations are set in my gradle.properties while using Gradle 9.

org.gradle.parallel=false
org.gradle.configuration-cache=false

This is equivalent to setting --no-parallel --no-configuration-cache on the command line.

2 Likes
14

No, adding this config to your gradle.properties will disable configuration cache and parallel execution of Gradle for the whole project. :exploding_head: I would not recommend this, since you will see a huge decreased in performance for most projects.

Also we use configuration cache for 2+ years without any issues. Why should you also disable this?

Workaround should be just executing the sonar task like this (as pointed out in #6):
./gradlew sonar --no-parallel

15

I’m just providing details about the steps I took to get it working on my setup. This information might help others keep using the sonar task in the meantime, until we can explore solutions for improved compatibility.

As you said, adding -no-parallel doesn’t solve the entire issue.

16

I think there is some confusing and/or misunderstanding.

Still I would not recommend people to modify their Gradle project configuration, when the only issue is about the single sonar task. Also the statement about this approach being “equivalent” is not true from my perspective.

Sorry, maybe I didn’t make it clear enough, but the error message in the quote only occurs without adding –no-parallel.

So the initial workaround by just adding no-parallel at task level should be enough and was actually provided by a Gradle employee for an different plugin that faced this issue.

17

I’m facing the same issue in my project

Resolution of the configuration ‘:SomeSubProject:compileClasspath’ was attempted without an exclusive lock. This is unsafe and not allowed.
For more information, please refer to https://docs.gradle.org/9.0.0/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors in the Gradle documentation.

Adding –-no-parallel is only a viable workaround if you’re only running a single task. Personally, I’m running jacocoTestReport testCodeCoverageReport sonar and these tasks result in compiling the project and running all tests, so thats a few hundred tasks.

Have you created a bug ticket for fixing this now that Gradle 9 is fully released? That way I have something I can keep track of to know when it is safe to upgrade my gradle version.

If there is anything I can do to help (such as providing a reproducer project), let me know.

18

Hey team.

My understanding (as of this morning) is that we’ll look at better Gradle 9 support in the team’s next iteration. I don’t have a ticket to share yet.

2 Likes
19

@lbenedetto You do not need to execute these Gradle tasks in a single line, since they will be executed sequentially anyways (as far as I understand Gradle parallel execution only runs independent tasks from different modules in parallel). You should be able to just run:

./gradlew jacocoTestReport testCodeCoverageReport
./gradlew sonar --no-parallel

1 Like
20

Any update on this? 6.3.0.5676 was released yesterday but it is not fixing the issue.

As G00fY2 wrote, disabling parallelism is definitely not optimal.

21

You can track this at SCANGRADLE-245.

It’s scheduled right now for 6.4, not the recently released 6.3.

1 Like