Build scan argues about "Dependency resolution during project configuration may reduce build speed by resolving dependencies unnecessarily."

Help/Discuss scans.gradle.com
1

We get the following performance issue from the build scan result: "Dependency resolution during project configuration may reduce build speed by resolving dependencies unnecessarily."
We followed the link to the documentation but still don’t know what to do to avoid this problem. From our perspective, we follow the Gradle documentation about setting up configurations.
We get this error for every configuration we created in our build.

We have this in a projects configuration:

configurations {
  a.extendsFrom runtime
}
dependencies {
  a group: 'org.glassfish', name: 'javax.el', version: '3.0.1-b08'
}

Then we use this configuration in the same project in a custom java task like:

task·b(type:·JavaExec)·{
 classpath configurations.a
}

What are we missing?
What can we do to avoid that problem?

Thanks for any help.
Bye,
Martin.

2

Hi @mschaaf,

Thanks for reaching out to us.
Could you be more specific about the custom java task you are referring to ? Is it a subtype of JavaCompile ?

Thanks,
François

3

@Francois_Guillot Thanks for your answer.
It is a JavaExec task.
I updated the question.

4

Hi @mschaaf,

The build scan doesn’t yet do a good job of telling you where it is used in your build. To do that, you can add this script to the top of your build:

def afterEvaluation = false
gradle.projectsEvaluated {
    afterEvaluation = true
}

allprojects { project ->
    configurations.all { configuration ->
        configuration.incoming.beforeResolve {
           if (!afterEvaluation) {
               throw new Exception("Configuration $configuration.name of project $project.name is being resolved at configuration time.")
           }
        }
    }
}

The thrown stack trace should indicate where resolution is happening. If it’s not clear from the stacktrace, please share the trace with me (you can use private messages here if necessary) and I can help.

Thanks.

5

@luke_daley thank you for the code that helped us to identify the problematic configuration.
The build scan showed us all manually added configurations as problematic. But at the end
it turned out that it was enough to fix one problematic place where we iterate over the files of a config.

This is the problematic piece of code in a configuration of a copy task:

    coreProjects().each { plugin ->
       from plugin.configurations.job.files
    }

So the question is now how to do this copy task config lazy?

6

Hi @mschaaf

from accepts closures to defer evaluation of its arguments .
You could do

   coreProjects().each { plugin ->
       from { plugin.configurations.job.files }
    }

to evaluate it at execution time.

7

You can do

from plugin.cofigurations.job

No need for a closure, Configurations are already lazy file collections themselves.

8

@st_oehme and @Francois_Guillot Thanks for the fast answers. Both work for us.

@luke_daley We would like to let this code permanent in our build to avoid the same issue again. Do you see a problem in having that check enabled all the time?

9

@mschaaf it’s no problem to just leave that code in and active. I do this in quite a few projects.

10

Thanks for all the help and fast answers. Our problem is solved.

11

Hello, not sure if I should start my own question or use this one.

I get the same error and after adding the snippet you mentionned, I don’t understand the stacktrace.

A problem occurred configuring project ':collections'.
> Failed to notify dependency resolution listener.
   > Configuration kotlinScriptDef of project collections is being resolved at configuration time.

Here is a link to the buildScan

https://scans.gradle.com/s/srbx2z6yaan32/failure?openFailures=WzBd&openStackTraces=WzJd#top=0

It is in an android project with a pretty simple kotlin module:

// collections/build.gradle
apply plugin: 'java-library'
apply plugin: 'kotlin'

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
  implementation Libs.kotlin_stdlib_jdk7
}

sourceCompatibility = "7"
targetCompatibility = "7"