This message was deleted.

Or is there a list of configurations that can be resolved during configuration? The various

compileClasspaths

are probably needed to determine task dependencies, so those should be ok, no?

compileClasspath

and similar are usually resolved on execution when they are required for some compile task, same with code generation plugins if they are written correctly using lazy APIs. If you just want to catch who resolves configurations before execution you can try execute some task like

help

with init script to delete all repos from

dependencyResolutionManagement

and `Project`s. Another place to hook could be

ConfigurationInternal#beforeLocking

but I'm not sure when exactly it's fired and keep in mind that it's gradle internal interface so it's intrinsically unstable to depend on it

I don't need stable, this will probably be a one-off or at most occasional thing to look at, so I can try that, thanks. I don't understand how

help

would work, though, since configuration-avoidance prevents configuration of tasks that are not executed, so that's not good, no? Something like

assemble -m

might work, but that still won't tell me which task is causing the resolve, which is what I actually want to find out

You're right,

help

shouldn't trigger materialization of tasks in

TasksContainer

but could catch those which used eager api. And after that you could call

tasks.all { ... }

to materialize all tasks in configuration phase. Idea with removing repos (and removing cache or pointing to empty gradle home dir) is to break on tasks which resolved configurations before execution phase. I've never had issue similar to yours so suggestions above are just some ideas on possible approach

I'm not even sure we have issues there, tbh, but that's just what I want to find out. There seems to be quite a bit of work done in resolution during configuration phase according to the output, but it could be normal for a project of that size.

There could be legitimate reasons to do resolve in configuration phase (like configuring

pluginsManagement#plugins

or adding version catalogs) but most tasks shouldn't require it. Good luck with identifying if there are such issues. I'd be interested to hear which approach works afterwards in case I have to do something similar in future.

Doing

gradlew build -m -i

on a clean cache dir looks promising, the log shows me for which task something is downloaded. Most of what I see there is ok, or at least probably unavoidable. Thanks for the helpful discussion, this got me thinking in a new direction!