This message was deleted.

There is some info in this thread where I got BuildService working: https://gradle-community.slack.com/archives/CAHSN3LDN/p1643763774027789 (more than halfway down that thread) in case it helps you a bit.

The build service actually does the job. My problem is, that calling

maxParallelUsages.set(Provider<>)

with a

Property<>

actually doesn't work as I expected. Even though the

Property<>

changes its value via build script, the service always uses its initial value.

Looks like a current limitation of `registerIfAbsent`: https://github.com/gradle/gradle/blob/e27ff70a01ca1e7d73be00e17a8f89a6b5ece27b/sub[…]/gradle/api/services/internal/DefaultBuildServicesRegistry.java

Why do you think the eager execution of the configuration action is the problem? That should still just associate the two properties, shouldn't it?

@VampireWell, the Build Service guide: https://docs.gradle.org/current/userguide/build_services.html To create a build service, you register the service instance using the BuildServiceRegistry.registerIfAbsent() method. Registering the service does not create the service instance. This happens on demand when a task first uses the service. If no task uses the service during a build, the service instance will not be created. And from the Lazy configuration guide: https://docs.gradle.org/current/userguide/lazy_configuration.html Gradle provides lazy properties, which delay the calculation of a property’s value until it’s actually required. I simply assumed that if the configuration action binds two properties, that once the property is actually needed that it will load it from actual value. If the action is evaluated eagerly, why it uses

Provider<>

type for the property? Provider type indicates lazy evaluation to me. It looks like that @Thomas Broyer hit the nail on the head. Thank you. So my only way to overcome this would be some sort of a configuration task which will be executed prior to the test task itself and which will set up the service in its action section.

My question was directed to @Thomas Broyer. I didn't read your whole code, but I don't think the linked comment is the culprit. Just executing this configure action eagerly just means the association between the two properties is eagerly done, not that the value is eagerly calculated.

Just executing this configure action eagerly just means the association between the two properties is eagerly done, not that the value is eagerly calculated.

Yop, that is correct. But during the execution phase,

maxParallelUsages

has the initial value of the

maxParallel

property. So it doesn't evaluate lazily as I would expect.

@Vampire, look 4 lines below (line 123) 😉 (this is related to the comment in that if the action execution was deferred then evaluation of the property would also be deferred; I link to the comment to emphasize the "current limitation" that could be lifted in a future version, rather than a "by design" decision)

Ah, sorry, I'm blind