From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Can the new problems API be used conditionally based on a `Provider` in the configuration phase?

If I want to throw based on a property, I must do that inside of a task? I would like to throw before any task is executed.

&gt; I know there is a <#C07UNDEAF6K|> channel, but it has almost no members yet


I have not played with the problems API yet.
But I'd say it is the same problem as always.
If you `get()` a provider at configuration time, you introduce ordering problems, timing problems, and race conditions, as the property could have the value changed after you retrieve its value.

I think the same... I would like to get configuration properties I could observer/combine so we don't need `afterEvaluate`

Anyway I have found a bug

I have found a bug with the `Problems` API when injecting it into tasks via constructor.

This fail:

```@CacheableTask
abstract class FooTask
@Inject constructor(
    private val logger: Logger,
    objects: ObjectFactory,
    layout: ProjectLayout,
    problems: Problems,
) : DefaultTask() {
    ...
}```
But this works

```@CacheableTask
abstract class FooTask
@Inject constructor(
    private val logger: Logger,
    objects: ObjectFactory,
    layout: ProjectLayout,
) : DefaultTask() {

    @Inject abstract val problems: Problems,
    ...
}```
I would expect both to be the same.

Meanwhile, injecting via constructor in the `Plugin&lt;Project&gt;` class is working.

I converted this to a GitHub issue: <https://github.com/gradle/gradle/issues/31958>

Hi <@U01DUV4Q882>,

I tried to reproduce this, I wasn’t able to.

Can you provide a <https://github.com/gradle/gradle-issue-reproducer|reproducer>?

thx

I have been able to reproduce it today again 

You can clone this project to reproduce it if you move it to the constructor:

<https://github.com/qonto/gradle-workshop/blob/main/build-logic/src/main/kotlin/com/qonto/QontoGenerateProjectDataTask.kt|https://github.com/qonto/gradle-workshop/blob/main/build-logic/src/main/kotlin/com/qonto/QontoGenerateProjectDataTask.kt>

Hi <@U01DUV4Q882>,

I found some time to look into this.

This is an expected behaviour.
not all services are available at construction time of the tasks, but they can be lazily injected via a getter.

Oh, that's surprising.
Especially as he said that injecting via constructor to the plugin class works.
The plugin class should be constructed before the task classes, shouldn't they?

Also, maybe it makes sense to inject some proxy in the constructor so that it would still work as long as the service is not used before it is available and otherwise show a meaningful error that the service will be available later but is not ready yet?

FYI, this only breaks with configuration cache.

a fix
<https://github.com/gradle/gradle/pull/34104>