Dumb question --- what’s the correct way to make a...

# gradle

[Patrick Ramsey]

Dumb question --- what’s the correct way to make a custom task that doesn’t take parameters? It seems like if I don’t specify any @Inputs, gradle complains that the constructor should be annotated with @Inject. If I annotate the task constructor with @Inject, gradle complains that the constructor doesn’t take any parameters.

[Patrick Ramsey]

https://stackoverflow.com/questions/65360274/custom-gradle-task-that-accesses-top-level-fails-with-the-constructor-shoul suggests that kotlin is quietly adding an implicit parameter, which is why gradle thinks it ought to be able to inject something

[Patrick Ramsey]

but I’m not sure what this parameter is!

[Patrick Ramsey]

it seems that calling copy {} from inside the TaskAction is what causes the failure.

[ephemient]

I believe it will all work fine if you define your classes in a .kt file (in an included build or buildSrc), but inside .kts things take a magic reference to the containing script

[Patrick Ramsey]

ahh 😕

[ephemient]

if you write project.copy {} instead of copy {} then that reference shouldn't be necessary

[Patrick Ramsey]

ohh. And that’s just my poor understanding of gradle. Didn’t notice that copy was a method on ProjectDelegate, not Task.

[Patrick Ramsey]

thanks. That solves that mystery.

[Patrick Ramsey]

yup, that did it. Thanks @ephemient!

[Vampire]

It's not so much magic and not Gradle specific. Things in a Kotlin script get compiled into a class, so if you define a class within the script it is an inner class. If in that inner class use something from the script, a reference to that outer class is necessary. If you use project., the project is taken from the task, so no reference to the script.

[Patrick Ramsey]

makes sense.

[ephemient]

in a normal class, you can't access the outer scope unless you explicitly write inner class ; that's not how top-level classes in .kts work though