when making an extension for a custom gradle plugin, which is more idiomatic for kotlin-dsl and is i...

# gradle

[Michal Klimczak]

when making an extension for a custom gradle plugin, which is more idiomatic for kotlin-dsl and is it just a design thing or does it matter for some other reason

//using just String
myPlugin {
    foo = "bar"
}

//using Property
myPlugin {
    foo.set("bar")
}

[mbonnin]

Property allows more laziness

[Fleshgrinder]

The difference is with dependency tracking, finalizing, etc. A standard Kotlin property is, well, a standard Kotlin property and it does not have any added functionality. A Gradle provider API type has all the aforementioned magic up its sleeve. So it really depends on what you need.

[Fleshgrinder]

We could also lazily configure the extension, however, that would be something only advanced users would know, so that's probably something to take into consideration just like you say:

myPlugin {
    foo.set(provider { "lazy" })
}

configure<MyPlugin> {
    foo = "lazy"
}

Actually I'm not sure if the latter is truly lazy… 🤔

Nope, it isn't, it's eager. Seems like there's no way to lazily configure extension like tasks. So, yeah, like @mbonnin said, laziness is another added thing.

[mbonnin]

Note that groovy allows to set Gradle Properties like if they were regular properties

[mbonnin]

(but not Kotlin)

[Fleshgrinder]

It would be possible in Kotlin (delegates), but Gradle is written in Java. 😞 Then again, it would add even more overhead to it, so probably not a good idea.

[Michal Klimczak]

thank you guys!

what would laziness mean in the context of providing such config? not really getting the specifics of how the gradle build is phased etc.

dependency tracking, finalizing etc seems like something I have to read up before I start asking more questions 🙂

[Fleshgrinder]

Laziness just means that the value is not computed until it is required. Imagine your extension configures the foo task. We execute the bar task, hence, nothing foo needs will be required. With an eager API everything for foo will be computed, even though we run bar. With a lazy API nothing gets computed for foo, since we run bar.

[Michal Klimczak]

phew, so just the regular stuff, thanks :)

[mbonnin]

https://docs.gradle.org/current/userguide/lazy_configuration.html

[ephemient]

it should be possible to have an extension defined with something like

@get:Input abstract val fooProperty: Property<T>
@get:Internal var foo: T by fooProperty

but it looks strange and is not worth the extra hassle, IMO

[mbonnin]

@ephemient Can you use Gradle Property as Kotlin property delegate?

[ephemient]

https://gradle.github.io/kotlin-dsl-docs/api/org.gradle.kotlin.dsl/org.gradle.api.provider.-property/index.html yes

[mbonnin]

Also I kind of like having helper methods instead of exposing var/Property:

myPlugin {
  foo("bar")
}

@tony wrote a nice article about this there: https://dev.to/autonomousapps/gradle-plugins-and-extensions-a-primer-for-the-bemused-51lp

[Big Chungus]

You can have both with some kotlin delegates. Here's some https://github.com/mpetuska/npm-publish/tree/master/src/main/kotlin/delegate