From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Not fully sure what you mean, but probably using `.all` on the collection?

Hm, I have an extension that’s has a DomainCollection as a member foo. The domain object registers a task during its init block. When I call extension.foo.register, the task isn’t registered because the extension.foo is never collected/called. I can call all in afterEvaluate, but I don’t want to use afterEvaluate at all. 

&gt; but I don’t want to use afterEvaluate at all
:ok_hand:

&gt; The domain object registers a task during its init block. When I call extension.foo.register, the task isn’t registered because the extension.foo is never collected/called.
Yeah, well, that's expected.
If you treat the container lazy by only using things like `register` and `configureEach` and so on, the elements are never realized and so their init blocks never called.
If you do `foo.all { }`, the laziness is killed - which might be ok, most containers in Gradle itself are also not treated lazily - but all of the elements get realized which is what you want, as the alternative, calling them in `afterEvaluate` would also need to do the same.

Yeah, but ideally Gradle itself realizes any DomainCollection/Providers of all extensions right before task realizing :thinking_face: 

It might be totally legit to not realize all elements but only the ones that are actually needed, just like it is with the elements of `tasks`.

If you as creator of a specific container want always all to get realized, it is your task to iterate through them, or call `.all { }` on them, or do any other action that causes all to be realized.

Besides that it is pretty uncommon, that the constructor of a domain object registers any tasks.

The typical thing is, that the plugin that creates the extension then for example attaches an `.all { }` action that registers the additional tasks, which then in turn would cause the elements to all be realized.

> Besides that it is pretty uncommon, that the constructor of a domain object registers any tasks.
It is? What is the preferred way to register tasks if you want to logically group them inside an extensions domain which creates multiple tasks?

Well, at least I've never seen any domain object before that registers additional tasks, but always the plugin that does it in reaction to domain objects being added like I described.

Thanks, I refactored my plugin/domain objects now. BTW I really want to have a lazy `elements` property of DomainCollection too, like `FileCollection.getElements()`.

The whole collection itself is the "lazy property", isn't it?

Nope, you can't map/transform the collection a lazy way, same for `FileCollection`.

Hm, right.
So maybe worth a feature request if there is none yet.