or is there a cleaner approach with kotlin dsl?

# gradle

[Marcel Overdijk]

or is there a cleaner approach with kotlin dsl?

[gildor]

nope, if you need to configure task you always provide name of task (using string + invoke, or using field delegates) and type of this task.
More cleaner approach is completely in hands of plugin creator, who can provide configuration API based on extension instead of tasks

[gildor]

@bamboo Is that planned to push plugin authors to use extensions to configure default task settings, instead of configure them directly, I’m talking about some kind “best practices” guide.
Also, would be nice to see this approach in Gradle Core plugins
Because with Groovy it looks identically, but with Kotlin DSL task configuration still looks awkwardly to be honest, and even if dsl will be improved, you should know task class to configure it.

[bamboo]

I’m sure @bmuschko would have much more to say about it but I think that’s always been a “best practice”. I see it as a sort of porcelain/plumbing sort of thing, extensions are porcelain, tasks are plumbing. Or to use another analogy, extensions to make the easy jobs easy, tasks to make the hard jobs possible.

[bamboo]

and even if dsl will be improved, you should know task class to configure it.

[bamboo]

We are considering providing accessors for tasks known after plugin application but indeed that will still leave out some tasks.

[bamboo]

Any suggestions on how to make build authors life easier in that regard is very much welcome.