What is detachedConfiguration? I have a lots of them for each subproject and resolving them takes 95% of build time

Help/Discuss
1

My all-UPDATED build take 30 sec, execution takes 2 sec. Rest of the time Gradle resolves dependencies for detachedConfiguration.

Each subproject has about 160 detachedConfiguration.

procmon can’t spot network activity but show lots of drive storage IO (100KB String BOM pom file is read so many times that total IO is 150MB!!).

I use:

apply plugin: 'com.jfrog.artifactory'
apply plugin: 'io.spring.dependency-management'

gradle --debug reveals some details:

[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Resolve dependencies of :core:detachedConfiguration80' started
[org.gradle.api.internal.artifacts.ivyservice.resolveengine.DefaultArtifactDependencyResolver] Resolving configuration ':core:detachedConfiguration80'
[org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.DependencyGraphBuilder] Visiting configuration com.batch:core:2.9.0-SNAPSHOT(detachedConfiguration80).
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Resolve dependencies of :core:detachedConfiguration80'
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Resolve dependencies of :core:detachedConfiguration80' completed
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Resolve files of :core:detachedConfiguration80' started
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Resolve files of :core:detachedConfiguration80'
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Resolve files of :core:detachedConfiguration80' completed

Each detachedConfiguration is resolved into one JAR file.

I am fighting with long dependency resolutions (this is typical top from --scan):

:subproj0:testCompileClasspath 1.554s  
:subproj1:compileClasspath 1.541s  
:subproj2:testCompileClasspath 1.288s  
:subproj3:testCompileClasspath 1.250s  
:subproj4:testCompileClasspath 1.229s  
:subproj5:testCompileClasspath 1.223s  
:subproj6:testCompileClasspath 1.207s  
:subproj7:testCompileClasspath 1.192s  
:subproj8:testCompileClasspath 1.187s  
:subproj9:testCompileClasspath 1.185s  
:subproj10:testCompileClasspath 1.181s  
:subproj11:testCompileClasspath 1.168s  
:subproj12:testCompileClasspath 1.164s  
:subproj13:testCompileClasspath 1.163s  
:subproj14:testCompileClasspath 1.153s  
:subproj15:testCompileClasspath 1.150s  
:subproj16:testCompileClasspath 1.145s  
:subproj17:testCompileClasspath 1.144s  
:subproj18:testCompileClasspath 1.121s

After resolving those detachedConfiguration I see human readable:

Resolving configuration ':core:detachedConfiguration169'
Resolving configuration ':core:testAnnotationProcessor'
Resolving configuration ':core:compileClasspath'
Resolving configuration ':core:annotationProcessor'
2

I am using Gradle 4.10.3 and have enabled in settings.gradle:

if (settings.hasProperty("useLocalTp") && file('../proj-tp').exists()) {
    logger.lifecycle("Using local TP project!")
    includeBuild '../proj-tp'
}

When I disable it (by commenting entry useLocalTp in ~/.gradle/gradleproperties) build time is reduced from 30 sec to 11-12 sec. It is again all-UPDATED builds.

3

Hi Oleksandr,

can’t explain what exactly a detached configuration is, but I remember similar problems from when we were using the Spring dependency management plugin. I think it has to do with how the Spring plugin “misuses” configurations to achieve it’s goal. I think @st_oehme explained it in a GitHub issue, but can’t find it right now, sorry.

TL;DR: If possible, try the platform/enforcedPlatform dependency configuration mechanism instead of Spring’s dependency management plugin. It requires Gradle > 5, though: https://docs.gradle.org/5.0/release-notes.html#dependency-version-alignment

Cheers
Axel

1 Like
4
5

I came across this very informative explanation of what detached configurations are by a Dependency Management Plugin contributor (@Andy_Wilkinson):

I have also seen those detached configuration messages in a couple of my projects. I wondered what they were too. It would never have occurred to me that it’d be something to do with a Spring plugin. So thanks for bringing it up, OP.

1 Like
6

Thanks for the link @lingocoder, didn’t know about that exclusion flag in the spring plugin at all :slight_smile:

Regarding the detachedConfiguration topic: I believe there are also some of those in our new project structure (which uses platform). So they are not exclusive to the Spring plugin.

7

I set:

dependencyManagement {
    applyMavenExclusions = false
}

and all-UPDATED build time reduced from 30 sec (28 sec spent in detachedConfigs) to 5 sec. It is the WIN!

Next thing is to turn off 'io.spring.dependency-management' plugin in flavor to build-in capabilities of Gradle.

Gradle supports BOM starting from v4.6.

1 Like
8

:open_mouth: It worked for me too. Awesome

9

Hi @gavenkoa can you please tell me to which file this configuration was added? Thanks Jamith

10

can you please tell me to which file this configuration was added?

You configure dependencyManagement per directory, so you can use in you root build.gradle with:

subprojects {
    apply plugin: 'io.spring.dependency-management'
    dependencyManagement {
        imports {
            mavenBom "org.springframework.boot:spring-boot-starter-parent:${projSpringBootVersion}"
            mavenBom "org.springframework.cloud:spring-cloud-starter-parent:${projSpringCloudVersion}"
            mavenBom "org.springframework.cloud:spring-cloud-gcp-dependencies:${projSpringGcpVersion}"
        }
        applyMavenExclusions = false
    }
}

You can use allprojects instead of subprojects or add a line to subdir/build.gradle:

dependencyManagement.applyMavenExclusions = false