Can I set a simple variable (a

val

in Kotlin DSL) inside a Gradle convention plugin / precompiled script plugin, and access it from the project that applies the plugin?

If your consuming script is also in Kotlin yes.

Not being able to use Groovy is fine. But when I simple tried my approach, Gradle cannot resolve the variable. Do I need to prefix it with something?

Mmmm I'm almost sure I've done that before. You may need to add the import manually?

I don‘t think it‘s possible because the code inside a pre-compiled script plugin is wrapped into an apply(Project) method of a generated plugin class. Usually your plugin would register an extension and that extension could expose a val or a provider of the value (to make it more idiomatic)

Usually your plugin would register an extension and that extension could expose a val or a provider of the value (to make it more idiomatic)

True, but that's something I wanted to avoid to just quickly extract some common property that I set in all of my project to the convention plugin, for common use.

the code inside a pre-compiled script plugin is wrapped into an apply(Project) method of a generated plugin class

Oooh that makes sense.

Another way of centralizing a static value is putting it into the top level gradle.properties file. This way you can access it from every project with

project.properties["name-of-the-prop"]

Unfortunately, the value is not fully static, but determined based on environment variables. So it's static per run, but might change between runs.

Beware of potential caching issues that might create. Depending on where that plugin and property are used, it can prevent cache from being re-used when it changes.

Depending on the value of the variable, you could put it in a kotlin file that’s part of the precompiled sourceSet. You would still need an import.

(also another reason to not use kotlin-dsl )

@Martin another? I'm not aware of any reason not to use

kotlin-dsl

. But actually all you answers here do not really match, as OP asked about precompiled script plugin and you said yes and you used it like that but also said you don't use

kotlin-dsl

but only

embedded-kotlin

, which means that you cannot even use Kotlin DSL precompiled script plugins. And even if you never use precompiled script plugins - which basically are just syntactic sugar over a normal binary plugin - it still makes sense to use

kotlin-dsl

, as it not only enables Kotlin DSL precompiled script plugins, but also brings some other benefits like the

kotlinDsl()

dependency, and various compiler plugins with their configuration like the

sam-with-receiver

plugin for the

Action

methods and the assignment to

Property

`val`s plugin, ...

@Vampire I try to stay clear of

kotlin-dsl

because it fragments the ecosystem for little value IMO. Having to remember all the differences vs regular Kotlin is a lot of cognitive load. I would also argue that

kotlinDsl()

adds unecessary dependencies. All of that is personal preference so I won’t be dying on this hill but IIRC, there are also performance issues with them like https://github.com/android/nowinandroid/issues/39. Unless those were fixed recently?

I think you still mix things up. If you are arguing against Kotlin DSL precompiled script plugins for any reason, that might be fine. But as I said, Kotiln DSL precompiled script plugins are only one aspect of what

koltin-dsl

adds.

kotlinDsl()

is the Gradle Kotlin DSL like many extension functions and so on. And also the added Kotlin compiler plugins and so on. Not using

kotlin-dsl

also fragements the ecosystem, as the Gradle code in plugins looks much different from the Gradle code in build scripts. 🙂

Yes, I’m basically ranting about the whole confusing situation.

Well, of course always depends on what ecosystem you are look at exactly 🙂

Yup