This message was deleted.

No, there is no way, except if you control both plugins.

where the extension property type is a NamedDomainObjectContainer, one can use `whenObjectAdded`to register a callback.

@Vampire yep I control both plugins!

Then don't have a property in extension

A

but have a method that does the configuration and that can then inform interested other parties like plugin B or similar.

@Chris Lee I can't use a provider/property bc they don't allow notification when the property is set - it still needs to be pulled

fair enough, though for a set of use cases it may be possible to avoid the notification and create a derived provider that pulls in values at resolution time.

Yep, @Vampire my question is just about what type to use, instead of manually managing callbacks

You probably have to do it manually. You can have internally `Property`s that you set from the method call and expose them as `Provider`s so that they can be wired to other properties easily.

I need to execute the callbacks before

afterEvaluate

but after the property is set. The property is set once during evaluation, so I need to execute the registered callback immediately once it's set

something like

fun propertyA(value : String) {
  propertyA.set(value)
  callbacks.forEach {
    it.execute(value)
  }
}

FTR I went with this solution:

abstract class ModuleConfigPluginExtension @Inject constructor(
    project: Project,
    objects: ObjectFactory
) {
    private val projectPath = project.path
    private var module: Module? = null

    private val moduleCollection: DomainObjectCollection<Module> = objects.domainObjectSet(Module::class.java)

    fun setModule(module: Module) {
        if (this.module != null && this.module != module) {
            error("`${projectPath}`: Module has already been set with a different value. Module can only be set once")
        }

        if (this.module == null) {
            this.module = module
            moduleCollection.add(module)
        }
    }

    fun whenAdded(block: Module.() -> Unit) {
        moduleCollection.configureEach {
            block(this)
        }
    }
}

then plugins can use this extension function:

fun Project.whenModuleConfigAdded(action: Module.() -> Unit) {
    the<ModuleConfigPluginExtension>().whenAdded(action)
}

neat!

I think there’s a gap in the gradle APIs because when I line up code with

afterEvaluate { }

- I actually don’t about all evaluation - just evaluation of a specific plugin/extension

that’s the premise for the Property/Provider API - allowing them to be resolved as-needed, at execution time, sidestepping the race-condition of afterEvaluate (ordering of listeners, etc). Of course, that presumes that all APIs are using Property/Provider, and a few other gaps.

yeah. Unfortunately cannot use

Property/Provider

to react to value changes at configuration time

you often don’t actually need to do that - chaining providers together and creating derived providers satisfies a swatch of use cases. your use case (a list/set of elements to respond to) isn’t handled by the Property/Provider API, though Gradle does still offer an option.