Avoid simplifying calls like obj.getProperty().get() and obj.getProperty().set(T) in your code by introducing additional getters and setters.
Does anybody know why that guideline would be proposed? In other words, what is the harm in writing/using a wrapper, especially for an internal getter? (I can sort of see how a setter would hide the fact that a lazily-configured property was in play and might prevent wiring up a property to another, which would hide the dependency relationship between 2 tasks from Gradle)
I’m willing to propose a PR to improve the documentation if I can better understand the intent.
Such getters and setters completely undermine the purpose of Property.
Not only a setter would hide the fact that lazy property is in play, getter would just the same.
If you would use the getter instead of the property, you cannot wire this to yet another property.
If you would use the getter you also would get the currently configured value instead of delaying it until needed.
Such getters might also make the user miss that it is a lazy property and could be used properly.
And as soon as you are calling the getter before the execution phase, you introduce race conditions again.
Optimally, you should never call get() (or any similar eager API) on a Property (or similar lazy type) before the execution phase.
Whenever you call it at the configuration phase, you risk that you miss further changes done to the property after getting the call, or if for example finalizeValueOnRead is called on it and then later someone tries to set it, this results in an exception.
Also nowadays with being able to use = to set Propertys, there also is not really any reason for such helper methods.
Just expose the property itself so that your consumers are aware what they are and can properly use them.