Apply inside of buildscript{}

Help/Discuss
1

I know that the buildscript{} configure the ScriptHandler by repositories{} and dependencies{}.
But, I saw some build.gradle file have a buildscript{} that containing apply:
buildscript {

apply from: new File(rootDir, 'dependencies.gradle')

repositories {
    jcenter()
    maven {
        url 'https://repo.spring.io/plugins-release'
    }
}

dependencies {
    classpath '...'
    ...
}

}

What this “apply” for inside of buildscript{}?
It looks it configure the Project object, but how it works inside of buildscript{}?
Is this not a syntax error for Groovy?

Thanks.

2

You can see from the Project.buildscript(Closure) javadoc that

The given closure is executed against this project’s ScriptHandler . The ScriptHandler is passed to the closure as the closure’s delegate.

I can’t see any reference to an apply method in ScriptHandler so I’m guessing the method “bubbles up” to the project.

You could try adding “println buildscript.class.name” to your build.gradle to see what class it is. Perhaps the concrete class implements PluginAware. If it does, the javadocs should probably be updated (eg perhaps ScriptHandler should extend PluginAware)

3

@Lance, thanks for your reply.

It is org.gradle.api.internal.initialization.DefaultScriptHandler:

public class DefaultScriptHandler implements ScriptHandler, ScriptHandlerInternal, DynamicObjectAware

I can’t find information about “DynamicObjectAware”, but, it think it is not implements “PluginAware”.

What means “bubbles up”? Is this the syntax for groovy?

4

A groovy Closure can have a delegate. Groovy will attempt to match method invocations defined inside the closure to the delegate. Gradle uses the DELEGATE_FIRST resolve strategy on the closures within the gradle DSL which means that method resolution will first be attempted on the closure delegate, and if no matching method can be found it will “bubble up” to the owner which is usually the delegate of the wrapping closure.

At the root of the resolution tree is a Project instance which is the delegate of the whole script. Method resolution will always “bubble up” to the project instance where a matching method can’t be found on the closure delegate.

1 Like
5

Thanks Lance. I understand it now.