Gradle and lazy configurations

SonarQube Server / Community Build
,
1

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.

1 Like
2

Hey there.

Can you confirm what version of the Scanner for Gradle you’re using?

3

I am using the latest one, everything I shared above is after reading the current code, which is public on GitHub.

7

Hi @JavierSC,

We support lazy configurations for properties but in the following way: private Provider<Map<String, String>> properties;.
Does this help you solve your problem?

All the best,

Irina

8

As it is private, I have no way to use it.

9

@JavierSC,

There is a public setter method.
You can find it here: SonarTask.java - line 161

All the best,

Irina

1 Like
10

Hey :wave:

Those methods and properties are on the task, it should be great if they were added to the extension as it is the main way to configure sonar.

11

Hi @JavierSC,

To understand you precisely, please provide me with a small reproducer.
In SonarExtension.java Sonar configuration is provided by using the Action (Gradle API 8.3)

All the best,

Irina

12

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.

13

@JavierSC,

Let me summarise what has been concluded:

  • 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.

Hope this helps.

All the best,

Irina

14

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.

16

I am still having ordering issues due this problem.

to avoid breaking changes to existing uses of the extension

Currently, the Gradle plugin breaks a lot of good practices from Gradle, you cannot ignore that just to avoid doing breaking changes…

It is not only problems related to Lazy configuration and ordering issues, Isolated projects are “almost” here and the plugin is not compatible either. Supporting it will be a breaking change…

1 Like