I have two workarounds so far: 1. Add an object which has the property as an extension:

class MyExtension(
  private var currentPropertySetting: String,
) {
  var myNewProperty: String
    get() = currentPropertySetting
    set(prefix) {
      // do clever stuff here
      currentPropertySetting = prefix
    }
}
(existingPluginModel as ExtensionAware)
      .extensions
      .create("myExtension", MyExtension::class.java)

which allows this, which seems verbose:

existingPlugin {
  myExtension {
    myNewProperty = "some value"
  }
}

2. Add a function as an extension:

(existingPluginModel as ExtensionAware)
  .extensions
  .add(
    object : TypeOf<Function1<String, Unit>>() {},
    "setMyNewProperty",
  ) { newValue: String ->
    // do clever stuff here
  }

which allows:

existingPlugin {
  setMyNewProperty("some value")
}

This is less verbose, but apart from losing the setter feel to the DSL it leads to compiler warnings over the generated code, because

TypeOf<kotlin.Function1<String, Unit>>() {}

uses reflection, so ends up with

kotlin.jvm.functions.Function1

rather than

kotlin.Function1

as the type specified in the generated code, which kotlinc then warns about because you are meant to use

kotlin.Function1

.

(or really anything with

@SupportsKotlinAssignmentOverloading

but

Property

already exists so why not)

I guess I can just decorate a real

Property

with my own implementation that acts on

set

Hmm - was looking good, but the build file does not compile:

Line 6:   myNewProperty = "some value"
            ^ Val cannot be reassigned

I wonder why it thinks it's a val...

maybe it interacts with extensions in some weird way

if it's the latter, you need to

import org.gradle.kotlin.dsl.assign

because it's not in the default imports and the IDE won't suggest it

(Btw. afair "you could make your own type" will not work as shown, the assignment plugin does not call

set

, but

assign

)

but if it didn't work with

Property

then that won't work either

is there a hook where a plugin can act after the entire build script has been evaluated, but without a task being called? That might be a better place to read the property value and do my work

None you should use. That is exactly

afterEvaluate { ... }

which is highly discouraged, as the main earnings you get from using it are timing problems, ordering problems, and race conditions. Usually you should have `Property`s and similar types and wire those together, only evaluating at execution time. And if you need to do something at configuration time with the values, I usually recommend to have a function in the extension and do the code in the body of the function, eventually preventing that it is called multiple times if necessary. But also for that, I would use a proper extension object with the function and not the function directly as extension, as you most probably leave users of one DSL behind if you do it like that.

In a normal extension you can even with a function retain the "property-like setting", if you add one nesting layer. If the function in the extension is

fun foo(action: Action<Bar>)

and

Bar

has the `Property`s. Then you can set them like

myExtension {
    foo {
        bar1 = "x"
        bar2 = "y"
    }
}

and do the configuration in

foo

after evaluating the

action

.

The

Property

trick btw. works, I just tried it. But it has the same problem as the

Function1

trick. It only works properly with Kotlin DSL. With Groovy DSL you get "There's an extension registered with name 'myNewProperty'. You should not reassign it via a property setter."

So there then the original situation is swapped around and you could use

=

in Kotlin DSL, but need to use

.set()

in Groovy DSL.

But as I said, if you care for Groovy DSL compatibility, you shouldn't use it, as you there then need to call

.assign

manually instead of using

=

.