This message was deleted.

.configureEach

is evaluated as soon as an element in the container is realized. Most containers in Gradle are not treated lazily but realized eagerly, as there are usually only few elements anyway and they are often needed all anyway, unlike with tasks. I wonder why you not simply activate locking on each and every configuration, if you use locking anyway. But to answer your question, it might make more sense to not have a property in the extension for this, but a function which you give the names as arguments and then do the locking logic in that function.

we used to activate locking on all configurations, but it's really noisy, as it also includes a bunch of configurations unrelated to the final deliverables (e.g. jacocoAnt, jacocoAgent and spotless related detached configurations)

detached configurations are affected by locking? How did you make that? When doing

configurations.configureEach

you should not catch detached configurations afair.

hmm, I mis-interpreted the spotless configuration names with random suffixes as being detached 🤔 https://github.com/diffplug/spotless/blob/main/plugin-gradle/src/main/java/com/diffplug/gradle/spotless/GradleProvisioner.java#L111-L138

Probably more a bug in the Spotless plugin and it should actually use detached configurations

a function works like a charm, thanks for the help as always

Hm, the Spotless thing was at least a concious decision in the scope of https://github.com/diffplug/spotless/issues/815. But maybe if you open a fresh issue, complaining about the fact, they could do a different solution as also was depicted in that issue.