Question: Suppose I have this:

val container: NamedDomainObjectContainer<MyType>

container.configureEach { ... } // 1
container.all { ... } // 2

container.register("myItem") { ... } // 3

Is there an guaranteed order in which a new

MyType

is run? I'm experiencing a bug where people are expecting the order to be 1,3,2, but it isn't acting that way. (The reason for the order is because block 2 contains a task registration, which requires something set in block 3)

1 and 2 are definitely run before 3.

Oof. I think the problem I have is that I have a block 2 that has a task registration that involves a

get()

on the value set in block 3. eg.

interface MyType {
  val myProperty: Property<String>
}

container.configureEach { // 1
  myProperty.convention(...)
}

container.all { // 2
  tasks.register("$name${myProperty.get()}")
}

container.register("myItem") { // 3
  myProperty.set(...)
}

Because 2 runs before 3, the tasks have names that are not what is expected; people might be under the impression that 3 runs before 2.

Ok, quickly tested, even across

all

and

confiugreEach

it works like expected.

The question is, how would I get something like a "3 before 2" effect, if 3 is in a build script and 2 is in a plugin?

The bad way,

afterEvaluate

The domain object

MyType

has both information and metadata about the tasks being registered. 2 would be "resolving the metadata". Of course, 2 would, in theory, be available eagerly too.

Which metadata that you need it at configuration time?

It's user supplied metadata, meant to be a part of a task name. Then some other code would parse the name to recover the value or somesuch.

The best would probably be to not depend on this metadata for the task naming 😄