I'm trying to migrate a Gradle build to Kotlin, unfortunately my gradle knowledge is circa 2014, so ...

# gradle

[Steve Ramage]

I'm trying to migrate a Gradle build to Kotlin, unfortunately my gradle knowledge is circa 2014, so thinks like the Task Avoidance API, and stuff aren't stuff I'm familiar with.

My old build use to have stuff like :

classes.dependsOn += otherTask

But I'm struggling to figure out what the new version of that should be.

tasks.named("classes").dependsOn.add(tasks.named("otherTask"))

Complains with "Unresolved reference "depends on"

[Josh Eldridge]

This may be helpful https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:adding_dependencies_to_tasks

[Steve Ramage]

Yeah I was looking at that, the challenge was that I'm not defining or registering the task, it's built in from the Java Plugin. I just goggleed this again, and just found this resource, which is helpful https://docs.gradle.org/current/userguide/kotlin_dsl.html instead of just looking at the Migration Guide.

I guess the the answer is:

tasks.named("classes") {
  dependsOn("otherTask")
}

[Josh Eldridge]

Yeah I think you were on the right path, it just needs to use the closures instead of dot notation

[Steve Ramage]

26 errors to go!

[Steve Ramage]

Thanks for replying.

[Vampire]

Actually I think what you had before was never really the thing to do.
I actually never came across that syntax and I'm using Gradle since pre-1.0. 😄

Also whenever you use a dependsOn explicitly, you are doing something wrong, except the left-hand side is a lifecycle task. You should usually instead properly wire inputs and outputs together so that you get implicit task dependencies where you need them automatically.

And in Kotlin DSL you have type-safe accessors for plugins applied using the plugins { ... } DSL, so if you properly apply the plugin using that DSL, you can also just use tasks.classes { ... } instead of tasks.named("classes") { ... }. 🙂

[Steve Ramage]

Interesting, thanks @Vampire I'm not sure where the syntax came from, I think I just copied it from other things where you can += and it worked.

[Vampire]

Would usually just have been classes.dependsOn otherTask in Groovy DSL 🙂

[Vampire]

🤷

[Steve Ramage]

Yup, I checked the book I read, Gradle in Action, and yup it's that way there too. They do use += for things like source sets.

Truthfully I've never really understood the Groovy DSL and it's always bothered me not understanding.

[Vampire]

For me it helped that I read a book about Groovy first, when I started to learn Gradle.
Because then I could understand the DSL better and why things work how they work. 🙂
But anyway, nowadays I only use Kotlin DSL wherever possible anyway.

[Steve Ramage]

Yeah and I bought "Groovy in Action" many years ago but it was massive and then just read Gradle in Action, and that was good enough.

[melix]

About dependsOn being wrong: https://melix.github.io/blog/2021/10/gradle-quickie-dependson.html
With classes being a lifecycle task, you are almost certainly doing it wrong. What you want to describe is not "when I reach the classes state, then all classes should be compiled", but rather "this task needs the output classes of this other task on its compile classpath".

[Amanda Martin]

Late to the game, sorry. But the Gradle docs have a migration guide too that I find helpful