What is the best way to lazy configure other plugins in convention plugins based on other plugins tasks outputs or ValueSources? Assuming that extension does have non-lazy fields (e.g. String instead of Property). Should I skip extensions and configure Properties on tasks directly or is there a way to define non-lazy things lazy?

Not really, except for using the cursed

afterEvaluate

with all its drawbacks. If the task of that plugin uses `Property`s but the extension primitives, I'd say that plugin should get its ass up and properly finish the migration to the lazy API. How to best mitigate the situation is very hard to say from the generic description you stated. But if the tasks indeed have `Property`s and you know it is enough to set those, it might well be the best way to go, yes. Having an extension where you set properties is often just a way to influence multiple places or tasks with one setting or to have a nicer end-user DSL, so indeed things you might not care about when automating. But it really depends on the concrete details from case to case.

This is very specific case with Pact plugin: • extension: https://github.com/pact-foundation/pact-jvm/blob/master/provider/gradle/src/main/kotlin/au/com/dius/pact/provider/gradle/PactPublish.kt • task: https://github.com/pact-foundation/pact-jvm/blob/master/provider/gradle/src/main/groovy/au/com/dius/pact/provider/gradle/PactPublishTask.groovy Looks quite simple and I should be able to inject

pactPublish

directly into the task. And the whole reason for the convention plugin is to not configure that manually for each repository so I do not care about extension availability at all.

PactPublish

is not an extension. It is a data class that exists as property on the extension and as property on the task.

Is it any different when there is an object as extension field? (https://github.com/pact-foundation/pact-jvm/blob/master/provider/gradle/src/main/kotlin/au/com/dius/pact/provider/gradle/PactPluginExtension.kt#L12) My understanding was that with this setup

PactPublish

and all it's fields will be treated as regular types and not Properties and will not be lazy loaded. Even if it's not the case then still my instrumentation should be for whole

PactPublish

as specific fields are not lazy loaded so i cannot user Properties and Providers to configure them directly but I rather have to use map method or something like that to map to whole

PactPublish

You got it exactly right for the current situation. Either the extension field should be

Property

or the fields in those classes should be

Property

and individually wired to task inputs, depending on use-case. But having a "plain" property which has "plain" properties is bad for lazy-configuration.