This message was deleted.

Make methods instead of properties in your extension, do you can directly react and add the tasks. Or if you depend on multiple properties in combination, you could also make one method with argument

Action<TheActualPropertiesHolder>

and then in that method you can do the actions after all properties were configured and you can prevent the method being called again to prevent unexpected changes after you reacted for example.

Here's a bit more details of my case: 1. Objects of interest are stored in

NamedDomainObjectContainer<T>

2. New items can be added via the plugin extension

myExtension { container { register("name") { ... } } }

3. However I'm also listening for kotlin multiplatform plugion application and when it's applied I'm using details from that plugin to implicitly create some items in that container 4. The problem is that by the time my end-user's expension DSL is evaluated, implicit items are not yet present and not retrievable via

named("implicitItem") { ... }

But the user also applies the KMP plugin, doesn't he? So the plugin should already be applied and your implied items present when the users DSL executes.

Yes, the user is expected to apply kmp plugin, but it's optional. i.e. items are generated if kmp plugin is applied, otherwise the user is expected to register the items manually. However if the kmp plugin is applied, the user should still be able to further configure generated items. It's similar to how kmp generates sourceSets by targets that the user then further configures. My problem is that item generation is triggered by actions outside of my own plugin domain unlike sourceSet generation which is triggered by actions from within kmp plugin domain.

Still not sure what your problem is. If the user applied the KMP plugin and you reacted to that properly, then the

implicitItem

should already be available for further configuration in the user code directly.

I am using withPlugin, but unfortunately that's evaluated too late.

Works perfectly fine here. Besides that

container

is an unlucky name as the container method from

Project

kotlin DSL will be used instead. But I guess that was just an example, not the actual naming. Can you show an MCVE where it does not work?

What's MCVE? 😀

Lol, I've managed to spot my issue when preparing an MCVE for you. Thanks for the help!

That's one of the reasons for creating MCVEs :-)