This message was deleted.

Maybe I don’t understand example enough, what are the use cases for that?

Setting property on extension, allowing for notifying observers that can then create dynamic tasks, etc.

What is a use-case for that? Do you have an example in one of your plugins maybe?

it’s a recurring challenge for plugin authors to make their plugin configurable, where that configuration results in say dynamic task creation. The example in the snippet above is from a golang plugin, where consumers of the plugin can specify which target platforms they’re building for (via the extension DSL). Each specified target platform results in a a golang build task being configured/registered accordingly. All of which has to happen at configuration time.

So it seems like the target platforms would probably be in a DomainObjectCollection and then Gradle would need to provide some automation that at some point in time (end of configuration/before running tasks) it would realize the container and run the corresponding actions (aka register the tasks). With the callback it would work only if folks only add target platforms, though as soon as they remove a target platform then you can’t remove the task again.

one of the workarounds for this situations is to use a DomainObjectCollection with

whenObjectAdded

as the callback (which is where this all started); however, often the state (storing the list of platforms, in this example) isn’t required - only notifying some code that a platform was added (if you want to remove it, don’t add it in the first place). Modelling as an Observable makes it clear what the behaviour is.