Rafael Chaves

Personally, I tend to favor explicitness over magic, and for consistency, we should require explicit annotations (and that would be consistent with the other kinds of properties). Also, we should...

I see now. This is an example of a validation error for a property with build service type that does not have an annotation: ``` A problem was found with...

> the Task.usesService requirement is entirely unnecessary. For most scenarios, folks should use `@ServiceReference` and, in that case, `usesService` is not needed (as it is redundant). That is what `@ServiceReference`...

The choice between which service to use would need to be done at *configuration* time: At configuration time: ``` if (someConfigTimeCondition) { serviceToUse = productionService } else { serviceToUse =...

You are assuming the task would only be assigned the selected service - the choice would be external. That is one possibility. But the choice of which service to use...

Could you please enter a request for such feature? However, I am guessing it probably would look a lot like https://github.com/gradle/gradle/issues/16170, for which `@ServiceReference` was devised.

Also, assuming we can determine whether the consumed service does not specify `maxParallelUsages`, maybe we should not require usage to be explicitly declared, as AFAIK it brings no actual value.

They would be related, yes, but I think both things could proceed in parallel. There may be cases we can automatically infer service usage, and there may be cases we...

This has been postponed. We ended up [disabling the deprecation ](https://github.com/gradle/gradle/pull/31419)altogether in 8.12. We need to figure out a way of honoring things such as `maxParallelUsages` that works for non-task...

Folks, for those exploring the idea of sharing the configuration cache across machines, please note that starting in 8.6, the encryption key to be used by the configuration cache may...