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
For iOS/Web it will be stabilized with stabilizing these targets themselves. Also, we should expose uiTest for them, not uiTestJUnit4
JUnit5 support will be provided in the future in [this issue](https://github.com/JetBrains/compose-multiplatform/issues/2371)
## API Changes
- Testing framework is stabilized for Desktop
- `compose.uiTestJUnit4` is renamed to `compose.desktop.uiTestJUnit4`
Compose compiler plugin produces symbols with identical signatures. k/jvm and k/native do not check for clashes, while k/js does. We disable the checker in our gradle plugin, so our users do not need to add extra workaround on their side.
* Simplify resource management for iOS
Introduces new a new task 'sync<FRAMEWORK_CLASSIFIER>ComposeIosResources',
which collects resources from all source sets, included in iOS targets.
With this change:
* CocoaPods integration does not require any configuration or calling 'pod install' after changing resources.
* Important: existing projects need to remove 'extraSpecAttributes["resources"] = ...' from build scripts, and rerun `./gradlew podInstall` once!
* Without CocoaPods, the resource directory should be added to XCode build phases once.
Resolves#3073Resolves#3113Resolves#3066
1. Rename "compose.web" to "compose.html" in Gradle DSL
2. Rename maven artifacts (with backward compatible "relocation" artifact)
3. Rename "web" folder to "html"
Will do in support/1.4.0 branch
1. Move examples/web-* to examples/html/*
2. Rename Tutorials/Web to Tutorials/HTML
3. Rename "Compose for Web" to "Compose HTML Library" in the tutorials
* Improve DSL for setting a custom Compose Plugin
Fixes https://github.com/JetBrains/compose-jb/issues/2459
Readme: https://github.com/JetBrains/compose-jb/pull/2526
1. Add `dependencies: Dependencies` extension that is accessible in `compose { }` block
2. Add `Dependencies.compiler` property that can return versions of Compose compiler used by the plugin:
```
compose {
kotlinCompilerPlugin.set(dependencies.compiler.forKotlin("1.7.20"))
//kotlinCompilerPlugin.set(dependencies.compiler.auto) // determined by applied version of Kotlin. It is a default.
}
```
3. Add ability to set arguments for Compose Compiler. Now we can write:
```
compose {
kotlinCompilerPlugin.set(dependencies.compiler.forKotlin("1.7.20"))
kotlinCompilerPluginArgs.add("suppressKotlinVersionCompatibilityCheck=1.7.21")
}
```
4. Remove checks for different targets
We had a separate check for JS, when we released 1.2.0. It doesn't support Kotlin 1.7.20 at that moment.
It is hard to refactor this feature in the new code, so I removed it. It is not needed now and it had an ugly code. When we will need it again, we'll write it again.
5. Remove the `compose.tests.androidx.compiler.version` property from gradle.properties and remove `defaultAndroidxCompilerEnvironment`
Because they are used only in one test, and it seems there is no reason to use it in another place in the future
* Discussions
Previously, we were setting kotlin.jvmTarget version
to 1.8 if it was null or < 1.8.
As an unintended consequence we were also overriding
a version set by the jvmToolchain property.
So while users expected the jvmToolchain property
to set both jdk home & jdk target, we were quietly
overriding jdk target.
At the same time, Kotlin 1.7 sets the minimum
target version to 1.8 anyway, so our override
does not make sense with Kotlin 1.7+.
This commit removes overriding altogether.
Fixes#2511
* Added animated image component
* Simplified network request
* Resource load is now done in the IO Dispatchers
* Renamed constant to express better its use
* Refactored animated image component to use the default Image component instead of creating our own component
* Added missing keys
* Created new module resources & adapted AnimatedImage to it
* Minor: add cleanDirs util
* Generate constant for gradle plugin version
* Unpack icons using task instead of lazy property
Resolves#960
* Introduce K/N Desktop packaging for Mac
* Fix components script compilation
* Add script to run Gradle with Compose properties set up
It's useful for running a single task in
the included Compose build.
* Set default JVM target to 11 if it is lower
* Update Compose submodule
* switching to oel compose branch
* Implementation of OEL publishing
* Changed based on Code Review
* Revert `support` folder
Co-authored-by: Igor Demin <igordmn@gmail.com>
Since kotlin 1.5.30, kotlinx.serialization plugin is forced to run its transformations before any other plugin. This made compose and kotlinx.serialization compatible, therefore no need to warn about their simultaneous usage.
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
* Add a check that compose is used along with kotlinx.serialization
There's a known issue that both plugins can't be used in the same module (specifically for kotlin/js targets).
The compose gradle plugin will check for `kotlinx.serialization` and will show a warning.
* Fix PR suggestions
* Update WarnAboutComposeWithSerialization.kt
Update the link for the issue
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
Konstantin
Alexander Zhirkevich
Alexey Tsvetkov
Igor Demin
Oleksandr Karpovich
Nikita Lipsky
Emre Şafak
Omico
dima.avdeev
Philip Wedemann
Thomas Vos
Abdelilah El Aissaoui
Louis CAD
Shagen Ogandzhanian
akurasov
Nikolay Igotti