Currently, the properties configuration is not using lazy APIs, so the configuration phase time will be slower and it can have order issues. For example:
properties.property("sonar.sources", project.kotlinSrcDirs.get())
// `project.kotlinSrcDirs.get()` I need to get the property
// eagerly as properties is not compatible with `Provider` APIs
There I am collecting the source directories, if for some reason they are changed after Sonarqube is configurated, so the directories will be incorrect. If the property function accepts Provider<String> and later the task uses it, this problem would be gone.
It should be possible to get this working and, at first glance, without breaking compatibility as SonarProperties already accepts Object and SonarTask has the properties map private too.
We support lazy configurations for properties but in the following way: private Provider<Map<String, String>> properties;.
Does this help you solve your problem?
The problem is the plugin is not using any lazy property as the task does.
private Provider<Map<String, String>> properties
Ideally, I would be able to add the properties in a lazy way in the extension, and those properties should be a public API, so if I want to depend on them for other configurations in other plugins or tasks, I wouldn’t have any ordering issues as they are lazy
As they aren’t, I can be fetching them when they are not set yet, so they would be null or empty, later they are provided, but then it is too late.
The Provider API will be used in the task, but not in the extension to avoid breaking changes to existing uses of the extension.
Lazy configuration was already supported with the use of Action and Convention mappings. Gradle resolves convention mappings right before running the task.
Personally, I would like to be able to access some val properties: MapProperty<...> at least. Currently it is impossible to get any property from the Sonar extensions from outside the properties { } block.
