or even: ```tasks { "bower" { dependsOn("gulp_bower") } }```

# gradle

[gildor]

or even:

tasks {
    "bower" {
        dependsOn("gulp_bower")
    }
}

[Czar]

Will this override "build" or just add the dependency?

tasks {
    "build" {
        dependsOn("gulp_build")
    }
}

[Czar]

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

[Czar]

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]

Or, to save a line

val build by getting
build.dependsOn("gulp_build")

[gildor]

Yes, this syntax only for task creation

[gildor]

Or if you want configuration block for existing task:

val bower by tasks.getting {
    dependsOn("gulp_build")
}

[Czar]

then IJ complains bower is never used.

[gildor]

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

[Czar]

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]

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 🙂
And it is probably not gradle kotlin-dsl related, but core language feature

[gildor]

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

[gildor]

easier to do something like:
"build".getting { dependsOn("gulp_buld") }

[Czar]

you mean create extension function?

[gildor]

actually, you can use existing Gradle API for that:

tasks.getByName("bower").dependsOn("help")

[Czar]

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

[Czar]

LOL, obviously, how did I miss that 😄 Then my full task customization config becomes just

tasks {
	getByName("build").dependsOn("gulp_build")
	"gulp_run" { dependsOn("gulp_default") }
	"bower"    { dependsOn("gulp_bower") }
}

[gildor]

yes, actually something like that would be better semantically:

configure("taskName") {
 configure = "it"
}

[Czar]

isn't that how you configure extensions?

[Czar]

e.g.

configure<SpringBootPluginExtension> {
		mainClass = "com.example.BootApplication"
	}

[gildor]

Yes, I mean in context of tasks

[gildor]

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

[gildor]

Haha. actually even better:

tasks["build"].dependsOn("gulp_build")

[gildor]

there is get operator that works as alias for getByName

[Czar]

In my case tasks["build"] won't work, I already have tasks {} block, so I'd prefer to have all tasks there.

[gildor]

this["build"] or get("build")

[gildor]

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