gradle kotlin dsl - Can't use project extra properties in plugin block

Question

I have a multi-project build, and more often than not I find myself locking versions for artifacts across the board. So in my root project I define something like:

project.extra.set("pkgVersions", mapOf(
    "kotlin" to "1.2.0",
    "jooq" to "3.10.2"
))

val pkgVersions : Map<String, String> by project.extra

plugins {
    base
    kotlin("jvm") version "1.2.0" apply false
}

While I can use pkgVersions anywhere, including other subprojects:

val pkgVersions by rootProject.extra

jooq {
    version = pkgVersions["jooq"]
}

I am not able to do so inside a plugin block:

plugins {
    kotlin("jvm") version pkgVersions["kotlin"]
}

Gives me the error "pkgVersions can't be called in this context by implicit receiver. Use the explicit one if required". I am assuming this is because the implicit receiver should probably be the file's JVM impression? But instead it is using PluginDependencySpec. Trying an auto-complete with this@ shows only this@plugin. This is just a long-shot guess from me. But, any pointers on what I am supposed to do?

Also, while we are at it, is there a way to create a global type in gradle-kotlin-dsl, for instance:

data class MyBuildType(..)

and have it available everywhere WITHOUT using buildSrc? It's pretty straightforward with buildSrc and I don't mind using it, but just wondering.

Answer 1

According to documentation (see Constrained syntax subsection)

?plugin version? and ?plugin id? must be constant, literal, strings

There are some other notes related to your question in the following paragraphs:

The plugins {} block must also be a top level statement in the buildscript. It cannot be nested inside another construct (e.g. an if-statement or for-loop).

Can only be used in build scripts

The plugins {} block can currently only be used in a project’s build script. It cannot be used in script plugins, the settings.gradle file or init scripts.

Future versions of Gradle will remove this restriction.

So it is not possible to do this now.

There is a workaround to extract the plugin version and use it afterwards, but I personally find it ugly and prefer using explicit versions.