Consider the following task, defined in build.gradle:

def dir = file('data')

def listFiles(File dir) {
    dir.listFiles({ file -> file.isFile() } as FileFilter).name.sort()
}

tasks.register('listFiles') {
    doLast {
        println listFiles(dir)
    }
}

Expected Behavior

Calling a method defined in the build script should be allowed at execution time if the method doesn't call Project methods. Accessing variables defined in the build script should also be allowed if these values are serializable by the configuration cache.

Current Behavior

In case of the Groovy DSL, the configuration cache is safely saved, but the next run fails to run the serialized task, often with the "method not found" error. This behavior comes from #20126. Accessing script-defined variables works fine.

In case of the Kotlin DSL, the configuration cache entry cannot be serialized, because the captured script reference cannot be serialized. An instance of this is filed under #16080.

Context

Extracting methods is a useful feature to break up/reuse pieces of build script logic, recommended in the Gradle user guide.

The workaround is to use utility classes/objects as containers for these methods. This approach is, however, problematic for the variables in the Kotlin DSL, as these variables cannot be initialized with project-derived values at configuration time.