This message was deleted.

I tried something like that before and found that `all`/`whenObjectAdded` callbacks are executed with unconfigured object when it's added but before configure action from `create`/`register` is executed. You could overcome it by extending container and overriding one or two methods but it's a bit conterintuitive. Another approach is to provide your own method on extension which will add to the container and execute provided configuration callback and only then execute your code to consume configured object in the container. It seems the most robust approach or so it seems.

like this?

fun add(name: String, config: Action<MyType>) {
    container.add(objects.newInstance(MyType::class, name).apply { config() })
}

will depend on the container… but it could work

I'm not sure if it's exact issue that you have but callback stacking is thing-in-itself

I'm definitely interested in finding the most intuitive and maintainable solution to this problem! Thank you. I find this Gradle behavior very weird

Assuming

doThing()

is a piece of default configuration logic - my go to solution is using properties all the way through in my custom extensions. This allows for lazily providing configuration values based on other extension properties. Something like:

open class MyType (private val theName, objects: ObjectFactory ) : Named {

  val isTrue = objects.property<Boolean>().convention(false)
  val theThing = objects.property<String>().convention(isTrue.map { if (it) ... })
}

However, properties can be a bit weird to handle for plugin users, as you can't simply use the

isTrue = false

syntax. Because of this I tend to have the property as an internal which is then augmented by custom get/set to provide the interface for plugin users. Like

open class MyType (private val theName, objects: ObjectFactory ) : Named {

  var isTrue: Boolean
        get() = _isTrue.get()
        set(value) = _isTrue.set(value)
  internal val _isTrue = objects.property<Boolean>().convention(false)
  ...
}

There was an amazing explanation posted a while back, see [0] and [1]

the issue is that

doThing()

registers a task. So if

ifTrue

is false, no tasks get registered. If true, they're registered. So I can't just keep pushing things down with properties

Is registering the task in any case and running it only if the extension property is true an option? If not, then indeed

afterEvaluate

seems the most logical/understandable place to me...

yeah, registering all with a task and then using

onlyIf

to run it only when a property is true would seem to be the sanest solution to me

I think avoiding registering a task that won't be used is a reasonable goal

reasonable goal it may be, but it's not achievable cleanly (IMO)

this seems clean enough to me

val c = objects.newInstance(MyType::class.java, name).apply {
    config.execute(this)
}
container.add(c)

🤷

you don't know that the collection uses the same instantiator, and it violates the expectation that

container.create("foo") { container["foo"]!! }

exists. although perhaps neither is important to you

I agree it's a fair point. This is a small project, though, and we can test to verify the functional requirements. I'd rather Gradle create an option to let us say "run the creation config immediately, that's why I used

create

_after all_", but who knows when or if that will ever happen

I looked through my code and that version was not committed, so no link to repo. Basically

create(String,Action)

and

register(String,Action)

have different behavior for observer using `whenObjectAdded`/`all`. •

create

instantiates object, adds to collection (and `all`/`whenObjectAdded` callbacks are called) and only then executes

Action

passed to callback. •

register

does opposite when realized, it instantiates object, executes passed

Action

(possibly decorated by

CollectionCallbackActionDecorator

which isn't applied to

create

AFAIK) and only then it is passed to `all`/`whenObjectAdded`. So I just override

create(String,Action)

when extend

AbstractNamedDomainObjectContainer

with one that has

add

and

configureAction.execute(object)

swapped. Original funtion: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/AbstractNamedDomainObjectContainer.java#L79-L80

ah, create/register differentiation strike again. How bizarre

yeah, I was quite surprised when found it

I never liked that combination of ordering for

create

on containers. I agree that it would be more natural to have the creation configuration to run first before adding to the container. However it has been like that for ages. But learning that

register

is different is concerning. I’ll raise that internally once more.

But to change behaviour in register too would be a breaking change. Idea about strict mode looks better with each version)

I'd prefer they change

create()

. Maybe we can get that for Gradle 8 🙏

Same here

Changing is really unlikely given the history. However pushing forward to deprecate then remove

create

and keep the behavior of

register

sounds like a good plan.

if you're going to make your own container, wouldn't it be more consistent to override

create(name, action) = register(name, action).get()

?

in this context, if I used

register

, would

all

still cause all elements of the container to be realized? In the current situation, I need those elements available during project configuration

all

should realize all objects in the container, yeah. When I wanted to create tasks lazily based on items in the custom container I just registered tasks based on object names and used actual object from the container on demand in configureAction.

// build.gradle.kts
abstract class Foo : Named
val foos = container(Foo::class)
foos.all { println("foos.all($name)") }
foos.register("bar") { println("foos.register($name)") }

prints

# ./gradlew
foos.all(bar)
foos.register(bar)

for me (Gradle 7.4.2)

Yeah, name added anyway. If you add some property to

Foo

and set it in register's configureAction vs same with create difference should become apparent

So @ephemient is right, there is no difference. Actions registered on the container with

all

are executed before the configuration action for both

create

and

register

. @grossws Would you be able to share a reproducer of what you did to see a difference? With the following in a

java

project:

configurations.all {
    println("Configuration ${this.name} can be resolved ${this.isCanBeResolved()}")
}

configurations.register("testFoo") {
    setCanBeResolved(false)
}

it prints

Configuration testFoo can be resolved true

@Louis Jacomet, I'll try to find where I got bitten by it and create a reproducer.