# Gradle alternatives to afterEvaluate for more explicit plugin configuration

DevFeed: [Gradle alternatives to afterEvaluate for more explicit plugin configuration](<https://devfeed.tech/articles/my-life-after-afterevaluate-25434.md>)

Original publisher: [Read original article](<https://blog.mbonnin.net/my-life-after-afterevaluate>)

Author: Martin Bonnin

Published: 2022-11-24T15:00:50Z

Content type: opinion

Language: en

Sources: [Martin Bonnin's blog](<https://devfeed.tech/sources/martin-bonnin-s-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Script](<https://devfeed.tech/topics/script.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [build](<https://devfeed.tech/tags/build.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>)

## AI overview

The article explains why relying on Gradle's afterEvaluate {} can make plugin and script dependencies implicit and fragile. It recommends exposing functions in plugin extensions for reading extension properties and configuring defaults, giving code more explicit control over execution timing.

## Source excerpt

If you're writing Gradle build scripts, chances are you have already used afterEvaluate {}. This is usually the last resort solution. But in my life of Gradle scripts engineer, I found the odds of afterEvaluate {} actually "fixing" your issue are in ...