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

Gradle Community

depends on what you need from the extension.  If it’s just properties, those can be chained and values will be resolved later.  If it’s more than that, one option is to use an observer pattern (NamedDomainObjectContainer.whenObjectAdded is one example).

there isn’t a clean way to know that the extension is configured.  Your approach will work in some cases - but fail when the consumer configures the extension multiple times.

everything in all extensions are plain values, no properties

Also your approach only works for usage in Kotlin DSL. If that is enough for you it might be ok of course, if it indeed takes precedence over the generated accessor.

If you want it for both DSLs properly, you can for example wrap the whole thing another level like
```myExtension {
    configure {
        ...
    }
}```

`configure` is a method of your extension in which you can verify that it is only called once and in which you can do your logic after applying the given closure

I thought about that but it looks ugly and I would add one more level of nesting and it already has a lot

But it is the proper way if you want a clean way.
As I said, if you only need to support Kotlin DSL and your solution works, it might be ok.
Maybe with an added check for multiple-invocation too.

There is no built-in way to be notified about an extension being configured, especially as that could also happen multiple times.

Personally I use my plugin in Kotlin, but it will be open source, if I could support Groovy without nesting should be great

should be great an API for this, as adding a nested extension is simpler to check if it is being called multiple times but the initial one is limited

the `afterEvaluate` is the only solution which can work with Groovy users without having an additional nesting?

Not sure if that can be very problematic tho, because currently my extension is just creating a huge state which is later mapped and configured, so the new configuration would be in the `afterEvaluate`, and that can be problematic with third party plugins I guess

`afterEvaluate` is not a solution but a hack and one that will fail on you as soon as someone configures the extension in an `afterEvaluate` block that is evaluated after your `afterEvaluate` block.
The only thing `afterEvaluate` does, is doing symptom treatment, delaying a problem to arise later again, but that time even harder to debug.
It always introduces nasty race conditions you cannot really avoid except by not using `afterEvaluate`.

_“Friends don’t let friends use `afterEvaluate`”_ :wink:

I usually use a Property if its configured in buildscript, or do plugins.withType targeting the plugin that configures the extension, if its configured by a plugin. Also, try to only read extension properties in the task execution phase, not configuration phase, if possible

&gt; or do plugins.withType targeting the plugin that configures the extension, if its configured by a plugin. 
&gt; 
If that plugin is not using `afterEvaluate` in which case it would break, also if it in a later version adds `afterEvaluate` for some reason, so there is a risk also with this approach. :-)