Provide more detailed error report about missing configuration value if it is computed

[ov7a]

Current Behavior

User gets an error about missing value. The information they get isn't complete: there is no indication that the value is computed. The solutions are misleading: user can't set computed value.

FAILURE: Build failed with an exception.

* What went wrong:
A problem was found with the configuration of task ':customJar' (type 'Jar').
  - Type 'org.gradle.api.tasks.bundling.Jar' property 'archiveFile' doesn't have a configured value.
    
    Reason: This property isn't marked as optional and no value has been configured.
    
    Possible solutions:
      1. Assign a value to 'archiveFile'.
      2. Mark property 'archiveFile' as optional.

Expected Behavior

User gets a descriptive error with a note about missing computed value and details about how it is computed and/or which configure values it depends on. Something like this:

A problem was found with the configuration of task ':customJar' (type 'Jar').
  - Type 'org.gradle.api.tasks.bundling.Jar' property 'archiveFile' doesn't have a configured value.
    
    Reason: This property isn't marked as optional and no value has been configured. This is a computed value based on 'destinationDirectory' and 'baseName'.
    
    Possible solutions:
      1. Assign a values to 'destinationDirectory' and 'baseName'.
      2. Mark property 'archiveFile' as optional.

Context

Current behavior might be confusing for new users. They can try to set a computed value and would get another error. See an example here.

Reproducer

[mlopatkin]

@gradle/bt-execution task input validation is currently in your domain, do you plan to handle this issue? Configuration team is ready to help with the plumbing if any is missing.

[asodja]

I will add it to our list and we can triage it when Lóránt is back.

[lptr]

The change required here is mostly pending on the provenance tracking feature of the provider API. Once that feature is available, we can update the message here to better attribute the problem.

[lptr]

We should clarify that archiveFile is not a Property and cannot be set. We should clarify that already.

[lptr]

Just for clarification: I think what is meant here is that it's a property of the task instance in the JavaBean sense, which is true for archiveFile. The message overall is still misleading, though.

[lptr]

We should distinguish between null values and absent Providers. When we find one latter, we can check if the provider implements HasConfigurableValue. If so, we can add the suggestion to specify a value for it, otherwise not. That would remove the misleading suggestion to specify a value for archiveFile.

If we wanted to actually explain where the current provided value comes from, for that we need support for provenance tracking first, which is a bigger undertaking that we should design more holistically.

[lptr]

BTW, is "computed" the terminology we want to use when describing providers being fed other providers as inputs?

[big-guy]

I don't think foo.set(otherProp) is "computing" anything, if that's what you mean. I would describe this as "otherProp provides the value of foo".

I could see saying "computed" when we fail to determine a value for a property. We use this in the documentation already to refer to "expensive computations" or "computed" values with zip. "determined" could also work in those contexts.

We could say "foo's value could not be computed from otherProp", but I would then expect we would say something like "otherProp's value could not be computed because its not known"

[FrauBoes]

A partial fix (improving the misleading proposed solution) will be addressed by:

• Improve error message if value derived from property that does not provide any value #25852

[lptr]

The rest is not a requirement for provider API migration, moving back to @gradle/bt-configuration-cache.

[ov7a]

See also:

• Confusing error messages when archiveDestinationDirectory is not set in the Jar task #18918