:wave: Is there a way to access `KotlinDependencyHandler` in `buildSrc` so we can call `implementati...

# gradle

[Filip Wiesner]

👋 Is there a way to access KotlinDependencyHandler in buildSrc so we can call implementation(...) there (using function with receiver e.g fun KotlinDependencyHandler.installDependencies(){}) instead of in build.gradle.kts?

[Javier]

you need to apply a plugin which has that functions

[Javier]

for example

plugins {
    kotlin("jvm")
}

[Filip Wiesner]

Inside the buildSrc build.gradle.kts file? All other buid.gradle.kts files that depend on it stop working (unresolved reference ... on every dsl function) if I try that.

[Javier]

No, in a precompiled plugin.

[tapchicoma]

add in buildSrc/build.gradle.kts :

dependencies {
"implementation"("org.jetbrains.kotlin:kotlin-gradle-plugin:1.4.30")
}

[irus]

dependencies {
"implementation"("org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.4.30")
}

[irus]

If plugin itself not required

[Filip Wiesner]

That worked! But I had to manually import the KotlinDependencyHandler and the function did not work with it as a receiver (had to pass it as a parameter). Thanks @irus

With the plugin dependency (not 'plugin-api') I was getting some ClassDefNotFoundException.

[irus]

I wish generated accessors also be available in buildSrc

[Vampire]

They are, in pre-compiled script plugins

[Vampire]

That worked! But I had to manually import the KotlinDependencyHandler and the function did not work with it as a receiver (had to pass it as a parameter).

Do you use the kotlin-dsl plugin?
Might be that it sets the sam-with-receiver compiler option so that it works the other way around

[Filip Wiesner]

I do have it. My build.gradle:

plugins {
    `kotlin-dsl`
}
repositories {
    jcenter()
}

dependencies {
    "implementation"("org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.4.30")
}

[irus]

They are, in pre-compiled script plugins

plugins {
    `kotlin-dsl`
}

repositories {
    mavenCentral()
}

val kotlinVersion = "1.4.30"

dependencies {
    implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlinVersion")
    implementation("org.jetbrains.kotlin:kotlin-serialization:$kotlinVersion")
}

But not in case of kotlin plugin in buildSrc, they not available in main sourceSet

[Vampire]

not sure what you mean. what is not available where?

[Vampire]

If you have a pre-compiled script plugin and there apply a plugin, its accessors are available

[irus]

This accessors not availble in buildSrc/src/main/kotlin

[Vampire]

Sure it is

[Vampire]

If you have a pre-compiled script plugin and there apply the plugin that adds this accessor. for the third time

[Vampire]

If that is true and you still have no accessor, please show an MCVE

[Javier]

those accessors are created by some plugin, if there is no plugin, there is no accessors. Is like trying to have Kotlin functions without applying a Kotlin plugin in a normal module.

[Javier]

you can create extension functions to do that trick, but the way to go is using precompiled plugins IMHO

[Javier]

internal fun DependencyHandler.implementation(dependencyNotation: Any): Dependency? =
    add("implementation", dependencyNotation)

[Javier]

internal fun DependencyHandler.api(dependencyNotation: Any): Dependency? =
    add("api", dependencyNotation)

[Javier]

etc

[irus]

@Vampire https://github.com/IRus/kotlin-dsl-accessors-in-buildSrc/blob/main/buildSrc/src/main/kotlin/MyKotlinJVM.kt#L14

[Vampire]

Yep, I don't even need to open that file

[Vampire]

This is not a pre-compiled script plugin

[Vampire]

Otherwise it would be named whatever.gradle.kts

[irus]

I wish generated accessors also be available in buildSrc ¯\_(ツ)_/¯

[Vampire]

The accessor generation works this way:
• take the plugins block from the script plugin
• apply it to a dummy project
• look what supported things like tasks, extensions and so on were added to the dummy project
• generate accessors for those added things
Now in the rest of the script plugin you can use these accessors.
If a plugin for example adds tasks dynamically depending on some extension configuration, those tasks will also not be available as they will not be added in the dummy project.

[Vampire]

The sense is, that only accessors are generated for things that are actually secured available and otherwise compilation fails.

[Vampire]

So in a normal kt file, you don't know which would be available

[Javier]

@irus they are in precompiled plugins, because you need a plugin. As I said before, you haven't the kotlin block from multiplatform plugin if you are only using the kotlin jvm plugin. This is the same. If you havent a plugin that has the dependencies block, why it should be there?

And this problem is no only in buildSrc, you can see that in a normal module where you only can access to the methods provided by the plugins you are using, not all method of all plugins in the world.

[irus]

I know how it works, and I know that after resolving configuration it technically possible to add resolved configuration from kotlin-dsl to buildSrc classpath

[Vampire]

I don't know what you mean by "resolve configuration", which configuration?
Do you mean you want the accessors just because the plugin is on the class path?
That would mean you would have to scan all classes on the whole class path for plugin classes, then apply all those found plugins to a dummy project and generate accessors for them.
And additionally somehow for Kotlin file generation default imports for those accessor packages would need to be added which is probably not even possible technically.
And all this has to be done magically before your code is compiled.
And it would just be broken by design as then you have accessors for the world and not only for what is actually present.
That would greatly decrease usefulness and lead to many runtime problems like you have with the Groovy DSL where everything is duck-typed.
Thus you would loose one of the biggest pros in using Kotlin instead of Groovy.
You are free to open a feature request with Gradle, but I doubt it would be done and actually also hope so. 🙂