Fix gradle-debug failing on configuration resolution

[AlexeyKuznetsov-DD]

What Does This Do

Fixes ./gradlew <task> -PddGradleDebug failing with:

Could not create task ':...:mule-4.5:extractMuleServices'.
> Resolution of the configuration ':...:mule-4.5:muleServices' was attempted without an exclusive lock. This is unsafe and not allowed.

The gradle-debug plugin now inspects tasks from gradle.taskGraph.whenReady (after the execution graph is built and scheduled tasks are fully configured) instead of force-realizing every task in every project from projectsEvaluated.

Motivation

The old code iterated project.tasks inside a projectsEvaluated BuildListener. Iterating the task container realizes every lazily-registered task, running its configuration action. Some tasks (e.g. mule's extractMuleServices, a Sync task) resolve a configuration in that action via resolvedConfiguration.resolvedArtifacts. projectsEvaluated runs without the project's exclusive lock, and current Gradle forbids resolving a configuration there — so the whole build aborted, even for unrelated commands like help.

Moving to taskGraph.whenReady fixes the root cause: at that point the scheduled tasks are already configured under the proper lock, so reading them is safe. It also avoids needlessly realizing every task in the ~200-module tree.

Additional Notes

• Behavioral change: the log now covers tasks in the execution graph of the requested command rather than literally every task. Run it against a real task (build, :module:test); help reports almost nothing.
• Added short usage docs to the plugin header (how to run, where the log lands, meaning of "jdk":"unknown").

🤖 Generated with Claude Code

[bric3]

That seems like the good approach indeed.

I wonder if the original issue with the projectEvaluated can be removed though. As they are usually bad in almost all usae cases (unless it's to verify things)

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	14.70 s	14.65 s	[-0.5%; +1.1%] (no difference)
startup:insecure-bank:tracing:Agent	13.62 s	13.60 s	[-0.5%; +0.9%] (no difference)
startup:petclinic:appsec:Agent	16.84 s	16.48 s	[+1.2%; +3.1%] (significantly worse)
startup:petclinic:iast:Agent	16.86 s	16.91 s	[-1.1%; +0.5%] (no difference)
startup:petclinic:profiling:Agent	16.23 s	16.87 s	[-8.1%; +0.5%] (no difference)
startup:petclinic:sca:Agent	16.91 s	16.78 s	[-0.3%; +1.8%] (no difference)
startup:petclinic:tracing:Agent	15.97 s	16.22 s	[-2.5%; -0.5%] (maybe better)

Commit: 60fa2514 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[AlexeyKuznetsov-DD]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-06-29 12:06:27 UTC ℹ️ Start processing command /merge

---

2026-06-29 12:06:36 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-06-29 13:18:32 UTC ℹ️ MergeQueue: This merge request was merged