or even ```tasks bower dependsOn gulp bower ```

Question

Czar · Answer

Will this override build or just add the dependency ```tasks build dependsOn gulp build ```

Czar · Answer

NVM found out that this fails this syntax is for creating tasks

Czar · Answer

Dependencies without creation in `tasks` block should be defined like this ```val build by getting val gulp build by getting build dependsOn gulp build ```

Czar · Answer

Or to save a line ```val build by getting build dependsOn gulp build ```

gildor · Answer

Yes this syntax only for task creation

gildor · Answer

Or if you want configuration block for existing task ```val bower by tasks getting dependsOn gulp build ```

Czar · Answer

then IJ complains `bower is never used`

gildor · Answer

I don t have warning if `val bower` is top level property

Czar · Answer

I do both in `project tasks ` and in `project ` on the build file s top level I don t need this task at all so `val by` then use it remains it s not too bad really

Czar · Answer

it would ve been cool if we could write `build by getting dependsOn gulp buld ` note no `val` Because this one line does everything we need and does not declare unused variable But I don t know how to even request this feature slightly smiling face And it is probably not gradle kotlin dsl related but core language feature

gildor · Answer

I don t think that such syntax make sense actually to strange in terms of language

gildor · Answer

easier to do something like ` build getting dependsOn gulp buld `

Czar · Answer

you mean create extension function

gildor · Answer

actually you can use existing Gradle API for that ``` tasks getByName bower dependsOn help ```

Czar · Answer

about making sense why it says delegate build to getting and do closure with it forget the result nobody cares

Czar · Answer

LOL obviously how did I miss that smile Then my full task customization config becomes just ```tasks getByName build dependsOn gulp build gulp run dependsOn gulp default bower dependsOn gulp bower ```

gildor · Answer

yes actually something like that would be better semantically ```configure taskName configure = it ```

Czar · Answer

isn t that how you configure extensions

Czar · Answer

e g ```configure lt SpringBootPluginExtension gt mainClass = com example BootApplication ```

gildor · Answer

Yes I mean in context of tasks

gildor · Answer

Oh tasks already have configure so impossible to use the same name

gildor · Answer

Haha actually even better ``` tasks build dependsOn gulp build ```

gildor · Answer

there is `get` operator that works as alias for getByName

Czar · Answer

In my case `tasks build ` won t work I already have tasks block so I d prefer to have all tasks there

gildor · Answer

`this build ` or `get build `

gildor · Answer

hmm I was sure that `tasks taskName ` works only with new tasks but it actually delegates call to maybeCreate so works with new and existing