CODEWITHSUNDEEP
kotlingradlegradle-plugingradle-kotlin-dsl
Tim
Tim

Reputation: 325

Gradle. Custom function in block plugins{}

Can i write in my custom plugin some function like kotlin("jvm")?

plugins {
    java
    kotlin("jvm") version "1.3.71"
}

I want to write function myplugin("foo") in my custom plugin and then use it like 

plugins {
    java
    kotlin("jvm") version "1.3.71"
    custom.plugin
    myplugin("foo")
}

How i can do it?

Upvotes: 2

Views: 1832

Answers (2)

madhead
madhead

Reputation: 33422

I think that plugins block is some kind of a macro expression. It is parsed and precompiled using a very limited context. Probably, the magic happens somewhere in kotlin-dsl. This is probably the only way to get static accessors and extension functions from plugins to work in Kotlin. I've never seen a mention of this process in Gradle's documentation, but let me explain my thought. Probably, some smart guys from Gradle will correct me.

Let's take a look at some third-party plugin, like Liquibase. It allows you to write something like this in your build.gradle.kts:

liquibase {
    activities {
        register("name") {
            // Configure the activity here
        }
    }
}

Think about it: in a statically compiled language like Kotlin, in order for this syntaxt to work, there should be an extension named liquibase on a Project type (as it is the type of this object in every build.gradle.kts) available in the classpath of a Gradle's VM that executes the build script.

Indeed, if you click on it, you'll see something like:

fun org.gradle.api.Project.`liquibase`(configure: org.liquibase.gradle.LiquibaseExtension.() -> Unit): Unit =
    (this as org.gradle.api.plugins.ExtensionAware).extensions.configure("liquibase", configure)

But take a look at the file where it is defined. In my case it is ~/.gradle/caches/6.3/gradle-kotlin-dsl-accessors/cmljl3ridzazieb8fzn553oa8/cache/src/org/gradle/kotlin/dsl/Accessors39qcxru7gldpadn6lvh8lqs7b.kt. It is definitelly an auto-generated file. A few levels upper in a file tree — at ~/.gradle/caches/6.3/gradle-kotlin-dsl-accessors/ in my case — there are dozens of similar directories. I guess, one by every plugin/version I've ever used with Gradle 6.3. Here is another one for the Detekt plugin:

fun org.gradle.api.Project.`detekt`(configure: io.gitlab.arturbosch.detekt.extensions.DetektExtension.() -> Unit): Unit =
    (this as org.gradle.api.plugins.ExtensionAware).extensions.configure("detekt", configure)

So, we have a bunch of .kt files defining all that extensions for different plugins applied to the project. That files are obviously pre-cached and precompiled and their content is available in build.gradle.kts. Indeed, you can find classes directories beside those sources.

The sources are generated based on the content of the applied plugins. It is probably a tricky task that includes some magic, reflection and introspection. Sometimes this magic doesn't work (due too chatic Groovy nature) and then you need to use some crappy DSL from this package.

How are they generated? I see no other way, but to

  1. Parse the build.script.kts with an embedded Kotlin compiler / lexer
  2. Extract all the plugins sections
  3. Compile them, probably against some mocks (remember that Project is not yet available: we're not executing the build.gradle.kts itself yet!)
  4. Resolve the declared plugins from Gradle Plugin repository (with some nuances coming from settngs.gradle.kts)
  5. Introspect plugin's artifacts
  6. Generate the sources
  7. Compile the sources
  8. Add the resulting classes to the script's classpath

And here is the gotcha: there is a very limited context (classpath, classes, methods — call it whatever) available when compiling the plugins block. Actually, no plugins are yet applied! Because, you know, you're parsing the block that applies plugins. Chickens, eggs, and their problems, huh…

So, and we're getting closer to the answer on your question, to provide custom DSL in plugins block, you need to modify that classpath. It's not a classpath of your build.gradle.kts, it's the classpath of the VM that parses build.gradle.kts. Basically, it's Gradle's own classpath — all the classes bundled in a Gradle distribution.

So, probably the only way to provide really custom DSLs in plugins block is to create a custom Gradle distribution.

EDIT:

Indeed, totally forgot to test the buildSrc. I've created a file PluginExtensions.kt in it, with a content

inline val org.gradle.plugin.use.PluginDependenciesSpec.`jawa`: org.gradle.plugin.use.PluginDependencySpec
    get() = id("org.gradle.war") // Randomly picked

inline fun org.gradle.plugin.use.PluginDependenciesSpec.`jawa`(): org.gradle.plugin.use.PluginDependencySpec {
    return id("org.gradle.cunit") // Randomly picked
}

And it seems to be working:

plugins {
    jawa
    jawa()
}

However, this is only working when PluginExtensions.kt is in the default package. Whenever I put it into a sub-package, the extensions are not recognized, even with an import:

enter image description here

Magic!

Upvotes: 3

Nicolas
Nicolas

Reputation: 7081

The kotlin function is just a simple extension function wrapping the traditional id method, not hard to define:

fun PluginDependenciesSpec.kotlin(module: String): PluginDependencySpec =
    id("org.jetbrains.kotlin.$module")

However, this extension function is part of the standard gradle kotlin DSL API, which means it's available without any plugin. If you want to make a custom function like this available, you would need a plugin. A plugin to load your plugin. Not very practical.

I also tried using the buildSrc module to make an extension function like the above. But it turns out that buildSrc definitions aren't even available from the plugins DSL block, which has a very constrained syntax. That wouldn't have been very practical anyway, you would have needed to make a buildSrc folder for every project in which you have wanted to use the extension.

I'm not sure if this is possible at all. Try asking on https://discuss.gradle.org/.

Upvotes: 0

Related Questions