Configuration resolved early, with included build and configuration on demand [154948828]

Fixed

Bug

Status Update

No update yet.

Description

je...@google.com

created issue #1

Apr 24, 2020 08:37PM

AndroidX is observing in

https://b.corp.google.com/issues/144998998#comment28 that project configurations are being resolved before task executions

It appears that this only happens when configuration on demand is enabled, and settings.gradle adds an includedBuild, and the com.android.library plugin is applied to a project.

I've simplified this down to a smaller reproduction test case: see

https://github.com/mathjeff/gradle-samples/tree/master/configuration-resolved-early to reproduce

Comments

je...@google.com <je...@google.com> Dec 8, 2020 06:57PM

Assigned to ga...@google.com.

ga...@google.com <ga...@google.com> Dec 14, 2020 02:21PM

Accepted by ga...@google.com.

ga...@google.com <ga...@google.com> #2Dec 14, 2020 04:37PM

The issue is with configuration on demand, as AGP relies on callback project.gradle.projectsEvaluated { ... } to start allowing for configurations to be resolved. With configuration on demand & composite builds, configurations need to be resolved in order to find which projects need to be configured. I think we need to listen for another event.

Message last modified on Dec 14, 2020 07:38PM

hu...@google.com <hu...@google.com> #3Dec 15, 2020 04:31PM

Adding a reference to what Ivan said: From https://docs.gradle.org/current/userguide/composite_builds.html#composite_build_intro, "Because of the reliance on dependency substitution, composite builds may force configurations to be resolved earlier, when composing the task execution graph. This can have a negative impact on overall build performance, because these configurations are not resolved in parallel."

ga...@google.com <ga...@google.com> #4Dec 16, 2020 11:27AM

Marked as fixed.

ag/Ice507db310bb268170566599138aea4b46b672e4 fixes this. It should be out in AGP 7.0.0-alpha05.

e....@gmail.com <e....@gmail.com> #5Jun 28, 2024 01:15PM

For anyone substituting module dependencies with projects, who aren't fans of the log spam: create an empty gradle build and include it.

gradle.properties

# fail build instead of endless warnings
android.dependencyResolutionAtConfigurationTime.disallow=true

settings.gradle

// include empty gradle project to suppress warnings and failures
// on dependency resolution at configuration time
// (caused by substituting modules with projects)
includeBuild("gradle/dummy")

gradle/dummy/settings.gradle

// intentionally left blank