=

✅

=

✅

=

❌

=

❌

A task inside a task does not seem right. Why is this needed?

This kind of "parent" tasks are managing multiple "child" tasks. Accessing them like this is not just there for convenience. While not all parent tasks do have task dependencies on its children, they should still re-run if any of the child's configuration changes. This happens to work pretty nicely with this @Nested pointing to the actual tasks ☺️

Mh. Usually. This is not a pattern that should be required. I haven't seen this before. :)

While not all parent tasks do have task dependencies on its children, they should still re-run if any of the child's configuration changes.

Maybe you can show a concrete use case? I don't quite understand what that means.

Probably just 💄 , but I would recommend making all task classes abstract instead of open.

Thanks for the hint! ☺️
Pushed a commit to change this ✅

Why do you need these extension methods and can not use property<T>() directly? It's already <T> not <T?>.

This is an interesting question:
So the issue that I have with properties is, that it was really hard for me to track whether or not I expect some value being present in a Property, or if it is actually, truly "optional". The current implementation of Property also does not care. It is like "can be there, might not".

Therefore, I started tracking my expectations of any Property myself in the Type-System:
The convention internally here is:

• Property<T?> -> No value required
• Property<T> -> Fail if value is missing

See this getSafe method, that I am using everywhere. This will use orNull if the type T is optional and get otherwise.

@OptIn(ExperimentalStdlibApi::class)
internal inline fun <reified T> Provider<T>.getSafe(): T =
    if (typeOf<T>().isMarkedNullable) orNull as T
    else get()

What exactly do you mean by "tracking expectations"? Is there any tooling that helps you here to ensure that the value is set?

Gradle should already do this for you. If you mark a property that you use somewhere as input with @Optional keeping it unset is allows (basically it is nullable) otherwise, you will get an error if it is not set.

You should use Property here. A property can always be unset and usually that should be enough and there shouldn't be the need to set it to null. You can still use @Optional to state that unset is a valid state.

You mean I should use a Kotlin property? var displayName: String? = null

Term property is quite overloaded. :)

This is what I mean:

val displayName: Property<String> = project.objects.property()

or, if you can make the class abstract, just:

abstract val displayName: Property<String>

Now I saw the other comment, which answers why you use <String?>. I'll answer there later.

Instead of objects.fileCollection() would be the better API if you just need an empty collection (If it is available in the Gradle version you want to support).

Even better would be to make the class and all the properties abstract. Like:

    @get:InputFiles
    abstract val sourceRoots: ConfigurableFileCollection

Then Gradle will inject everything and you have much less boilerplate. And you probably won't have to pass project and/or objects around.

Thanks a lot, I did not know about objects.fileCollection and I also did not know about the fact, that Gradle will inject into Abstract classes here as well, which is awesome!! 🤪

Pushed a commit for objects.fileCollection. Making this object abstract will require some tests to be adapted. I will wait for another PR to be merged first to tackle this! :)

Basically everywhere where you pass a class to Gradle so that Gradle does the instantiation, you can use an abstract class and will get an object of an instrumented subclass that does all these things automatically.