Question: Suppose I have this:

interface MyDomainObject : Named {
  val taskName: Property<String>
}

val myContainer: NamedDomainObjectContainer<MyDomainObject>
myContainer.configureEach {
  taskName.convention("task$name")
}

How would I properly register a task with the value of

taskName

? I was thinking that this is wrong:

myContainer.all {
  tasks.register(taskName.get())
}

So I was thinking maybe this might work?

myContainer.all {
  tasks.addRule("Rule registering task") {
    if (it == taskName.get()) {
      tasks.register(it)
    }
  }
}

I doubt

register

will work there. It also does not make too much sense, because if you reach there, it is clear the task is needed, so you can right away use the eager

create

. With that it might work, but consider that this also has drawbacks, for example the task will not be part of

tasks

output or shown in the IDE tool window or shown by CLI auto-completion and so on. Besides that, if you then have

taskName

at one value, request a task with that name, then change the

taskName

value and again request a task with that name, you probably end up with both of these tasks. You are right that your first version will not work, because you query the property before the consumer hat a chance to set the value for the property and also it could change later on unless you finalize the value of the property. Usually for stuff you need at configuration time, I recommend not to use properties, but function parameters. So where you have your

myContainer

instead have some function to which you give the name and optionally taskName as arguments and then this function could for example create the element in

myContainer

and register the task right away. Any remaining parameters for

MyDomainObject

you could let the consumer set for example in an

Action<MyDomainObject>

that he also gives to that function. But don't make the task name configurable in it again. Either have it there as read-only primitive property, or as

Provider

or not at all.

It may be enough to derive the task name from the name of the domain object. Asking users specify the name of the task in addition to the name of the object may end up putting too much burden on them.

It is not a burden but an option, as there is a default