Improve error message when build fails because of missing metadata
Gradle 6.0 removed the "artifact" metadata source by default.
This means that if a module is published _only_ with an artifact,
previous version of Gradle would find it, but 6.0 would fail with
a module missing exception.
The problem is that it's hard to realize that the issue comes
from the change of this default artifact sources.
This commit tries to improve the situation by recognizing that
a failure is related to not finding metadata, and in this case
would suggest that if the metadata is missing, it is still
possible that the jar is present.
The drawback of this approach is that we're unsure: if, for
some reason, the module is _really_ absent, then we gave a
wrong advice. This means, in particular, in case of wrong
19 Sep 19 05b34d01fc7753513a6a23214f021d6253fb8dc3
Finalize the value of any task `@Input` property whose getter returns a property instance, at the start of execution of the task.
This means that the property value will not change once the task has started execution, so that the same value is always used during fingerprinting, cache key calculation, validation, when queried by a task action, and so on.
This behaviour only applies to `@Input` properties in this commit. This was just a place to start. Other properties will be added in later commits.
Changes to the property are ignored once the value is finalized implicitly in this way and generate a deprecation warning instead of failing, as would happen after `finalizeValue()` is called. This allows a migration path for task types that can add a new property to represent some input and keep their existing lenient (but now deprecated) behaviour for an existing property backed by the new property. It might prove better to flip this around, let's see.
10 Oct 18 c2b96c1e20c9ab3093de71cd95eec8f48b69532b