compose-jb

Branch: chat_1.9.20-Beta

Alexey Tsvetkov eb124feb4b Fix reporting configuration problems with configuration cache (#3596 ) Sometimes we need to report warnings during the configuration phase. For example, when Androidx Compose Compiler is used with non-JVM targets (e.g. iOS/js), we want to warn users that using non-JB compiler with non-JVM targets is not supported. The default way of reporting warnings in Gradle is using a logger. For example we could write something like: ``` abstract class ComposePlugin : Plugin<Project> { override fun apply(project: Project) { if (project.hasNonJvmTargets() && project.usesNonJBComposeCompiler()) { project.logger.warn("...") } } } ``` This approach has a few issues: 1. When the Configuration Cache is enabled, project's configuration might get skipped altogether, and the warning won't be printed. 2. If a project contains multiple Gradle modules (subprojects), the warning might be printed multiple times. That might be OK for some warnings. But repeating exactly the same warning 10s or 100s is unnecessary. The only way to share the state between Gradle modules, while preserving compatibility with the Configuration Cache, is to define Gradle Build Service. In 1.5.0 we used Gradle Build Service mechanism for both warnings. However, I did not know that: * only the service's parameters are persisted in the Configuration Cache. The service itself is not persisted. * if a service instance is materialized during the configuration phase, then all changes made to its parameters will not be visible to that particular instance (but they will be visible to the next instance). So the only way to report diagnostics with configuration cache without repetition is to define a service that is not materialized during the configuration phase (i.e. serviceProvider.get() is not called), add to add warnings to a set property of the service. This change implements that. Resolves #3595	1 year ago
..
main	Fix reporting configuration problems with configuration cache (#3596 )	1 year ago
test	Fix reporting configuration problems with configuration cache (#3596 )	1 year ago

Fix reporting configuration problems with configuration cache (#3596 )

Sometimes we need to report warnings during the configuration phase.
For example, when Androidx Compose Compiler is used with
non-JVM targets (e.g. iOS/js), we want to warn users
that using non-JB compiler with non-JVM targets is not supported.

The default way of reporting warnings in Gradle is using a logger.
For example we could write something like:
```
abstract class ComposePlugin : Plugin<Project> {
    override fun apply(project: Project) {
          if (project.hasNonJvmTargets() && project.usesNonJBComposeCompiler()) {
               project.logger.warn("...")
          }
    }
}
```

This approach has a few issues:
1. When the Configuration Cache is enabled, project's configuration might
get skipped altogether, and the warning won't be printed.
2. If a project contains multiple Gradle modules (subprojects),
the warning might be printed multiple times. That might be OK
for some warnings. But repeating exactly the same warning
10s or 100s is unnecessary.

The only way to share the state between Gradle modules,
while preserving compatibility with the Configuration Cache,
is to define Gradle Build Service.

In 1.5.0 we used Gradle Build Service mechanism for both warnings.
However, I did not know that:
* only the service's parameters are persisted in the Configuration Cache.
The service itself is not persisted.
* if a service instance is materialized during the configuration
phase, then all changes made to its parameters will not be
visible to that particular instance (but they will be visible to the
next instance).

So the only way to report diagnostics with configuration cache without
repetition is to define a service that is not materialized
during the configuration phase (i.e. serviceProvider.get() is not called),
add to add warnings to a set property of the service.
This change implements that.


Resolves #3595

1 year ago

main

Fix reporting configuration problems with configuration cache (#3596 )

1 year ago

test

Fix reporting configuration problems with configuration cache (#3596 )

1 year ago