The recent compose core libs are built using 1.9.21, and apparently, older k/native versions don't support them.
e: kotlin.NotImplementedError: Generation of stubs for class org.jetbrains.kotlin.ir.symbols.impl.IrTypeParameterPublicSymbolImpl is not supported yet
Currently when `org.gradle.configuration-cache=true` we have an error:
> Configuration cache state could not be cached: field `resourceFiles`
of task `:shared:syncComposeResourcesForIos` of type
`org.jetbrains.compose.experimental.uikit.tasks.SyncComposeResourcesForIosTask`:
error writing value of type
'org.gradle.api.internal.provider.TransformBackedProvider'
Old description (can be ignored):
_This PR attempts to fix it in SyncComposeResourcesForIosTask by
wrapping inputs into providers. It seems that gradle configuration cache
doesn't like some provider types produced by `.map`, `.zip`, `.orElse`,
etc._
**Latest description:**
With configuration cache enabled, gradle runs all `orElse` providers
during configuration (I don't know why yet).
We used to throw an exception in `orElse` which led to the crash. This
PR refactors SyncComposeResourcesForIosTask so it doesn't throw an
exception immediately in orElse, but postpones it to later step.
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
* Fix cache kind management with nested subprojects
Previously, cache kind property management
worked incorrectly when Compose Gradle plugin
was applied to both parent and child subprojects,
e.g. :compose-subproject-1:compose-subproject-2.
With this example the plugin would successfully
set the property for compose-subproject-1,
but then for compose-subproject-2 the following snippet
would fail:
```
if (project.hasProperty(targetCacheKindPropertyName)) {
project.setProperty(targetCacheKindPropertyName, NONE_VALUE)
}
```
because project.hasProperty would have return true
(because it checks parent subproject properties too),
but project.setProperty would fail, because
parent project's properties are read only.
Warnings were also handled incorrectly in this case,
because during the configuration of compose-subproject-1 we might set
`kotlin.native.cacheKind.ios*=none`,
which would then cause a warning during the configuration of compose-subproject-2.
To avoid incorrect warnings, we now
record the snapshot of relevant properties
during Compose Multiplatform build service initialization
Resolves#3515
* Fix issues from code review
We tried to enable the compiler cache, when
Kotlin/Native 1.9.0 is used.
Prior to Kotlin 1.9.0, the caching could not
be used with Compose, because code generation would fail.
With Kotlin 1.9.0, code generation succeeds, but generated debug symbols cause issues with dsymutil during xcode build.
For more details, see https://youtrack.jetbrains.com/issue/KT-61270
This change partially reverts https://github.com/JetBrains/compose-multiplatform/pull/3477 and https://github.com/JetBrains/compose-multiplatform/pull/3496
Now, we always set `kotlin.native.cacheKind=none` in
Compose Multiplatform Gradle plugin for all
versions of Kotlin until KT-61270 is fixed.
Also, explicit cache kind error becomes a warning again.
* Add a warning for a user who sets `compose.kotlinCompilerPlugin` to `android.compose.compiler.compiler`
The warning will show up only when a multiplatform project contains at least one of the non-jvm targets: k/js, k/native or k/wasm
* fix typo
* PR review
* Refactor to BuildService
* fix typo
* Fix signing bundle with Gradle 8.1 with configuration cache
Compose Gradle plugin was launching
`/usr/bin/security --find-identity` in a lazy property of
AbstractJPackageTask. Without the configuration cache
the computation was delayed to the execution phase.
However, configuration cache serializes all properties of
all configured tasks, so launching of `/usr/bin/security`
shifted to the configuration phase.
Gradle 8.1 started to throw an exception if an external process is
launched during configuration time.
This change explicitly moves the call to
`/usr/bin/security` to the execution phase.
Resolves#3060
* Turn off Gradle configuration cache for one test
Previously Compose Multiplatform Gradle plugin required
JDK 15+ for distribution packaging. However, fixing #2867 required
always passing --mac-entitlements to jpackage, which is
only available with JDK 17+.
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
* Update Gradle used in tooling subprojects
* Update Kotlin in Compose Gradle plugin
* Decrease verbosity of Gradle plugin tests
* Disable mac sign test
* Add workflow to test Gradle plugin
* Fix custom jdk tests on Linux
* Make Compose Gradle plugin build compatible with Configuration cache
* Print tests summary
* Remove unused code
* Refactor tests configuration
* Turn off parallel execution
* Try adding windows runner
* Turn off fail fast
* Fix Windows test issues
#2368
* Adjust default proguard rules
The following rule is needed to fix tests on Windows:
```
-dontwarn org.graalvm.compiler.core.aarch64.AArch64NodeMatchRules_MatchStatementSet*
```
Other rules are just to make builds less noisy.
Kotlin's `*.internal` packages often contain
bytecode, which triggers ProGuard's notes.
However, these notes are not actionable for
most users, so we can ignore notes by default.
#2393
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
JS target supports a lower version (1.7.10), because we have a bug in Koltin 1.7.20
Compose 1.2.0 will support:
1.7.20 and 1.7.10 for Android and Desktop
1.7.10 for JS
We will release the new patchset (1.2.1) with 1.7.2X support for JS later
ProGuard support has introduced `Release` build type in addition to the default one.
Prior to that there was the `package` task, which did not do anything by itself.
The `package` task existed purely for convenience: instead of running
the `packageMsi` on Windows and the `packageDmg` on macOS, a user could
run the `package` task to package an application into a format suitable for a host OS.
A similar task for the release build type should be called `packageRelease`.
However, this name conflicts with a task created by the `com.android.application`
plugin.
This change deprecates the `package` task and removes the `packageRelease` task.
`packageDistributionForCurrentOS` and `packageReleaseDistributionForCurrentOS` should be used instead.
Resolves#2345
By default, the Compose Multiplatform Gradle plugin
uses `org.jetbrains.compose.compiler:compiler:<COMPOSE_VERSION>`
as a compiler plugin .
However, a new version of Kotlin might be incompatible with
the default version of compiler plugin. Previously, that forced
users to update to a new version of Compose Gradle plugin & Compose libraries
in order to use a new version of Kotlin. Accordingly, Compose framework developers
had to release a new version of all libraries, when a new version of Kotlin is released.
Some time ago the Compose team at Google made it possible to update a compiler plugin
without updating the Gradle plugin and/or all Compose libraries
https://developer.android.com/jetpack/androidx/releases/compose-kotlin
This change allows to specify a custom compiler artifact by using the following DSL:
```
compose {
kotlinCompilerPlugin.set("<VERSION<")
// or
kotlinCompilerPlugin.set("<GROUP_ID>:<ARTIFACT_ID>:<VERSION>")
}
```
Konstantin
Oleksandr.Karpovich
Igor Demin
dima.avdeev
Alexey Tsvetkov
Emre Şafak
Alexey Tsvetkov