#kotlin-dsl
Posts
-
Digging into Gradle's Source 6: Projects and Build Scripts — How build.gradle.kts Gets Run
What does one build.gradle.kts file turn into inside Gradle? We follow the code that builds DefaultProject from the descriptors settings left behind, the evaluator chain that runs under a project lock with its beforeEvaluate and afterEvaluate states, the selector that picks Groovy or Kotlin by the end of the file name, the two DSLs that cut out plugins {} and compile twice, the generated accessors that make tasks.compileJava possible, and the class loader scopes that run from settings down to subprojects, running the same script in both DSLs and printing a stack trace to check each step against the source.
-
Digging into Gradle's Source 7: Applying Plugins — From the plugins {} Block to apply()
What does a single plugins { java } line turn into in the source? DefaultPluginRequestApplicator resolves every request first and only then applies them all; a resolver chain asks core plugins, buildSrc, included builds and the Plugin Portal in turn, using marker artifacts; META-INF/gradle-plugins descriptors turn an id into a class; DefaultPluginManager runs a plugin only once even if you apply it twice; withPlugin fires at a precise moment; extensions get attached; java pulls in java-base and base; and buildSrc and precompiled script plugins fit in — all checked with a plugin we write ourselves.