* Fix `kotlinCompilerPlugin` property
[Support multiple versions of Kotlin PR](https://github.com/JetBrains/compose-jb/pull/2366) breaks `kotlinCompilerPlugin` feature.
`customPluginString` isn't set at the moment of plugin applying (or Provider's initialization), so we need to read it only when the artifact is requested.
* Refactoring
- Move cleaning up build directory from packComposeUikitApplicationForXCode Gradle task to registerConnectedDeviceTasks as the first one runs during xcode build and could delete files placed by xcode in parallel before (such as Info.plist).
- Remove workaround of running xcodebuild twice as the original problem the most probably was provoded by incorrect build directory cleanup
- Remove sources from xcodegen configuratiom as we do not need them in the resulting .app
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>")
}
```
6.4 is not supported by kotlin-gradle-plugin 1.7.0.
6.7.1 is supposed to be the min. supported version by kotlin-gradle-plugin 1.7.0. Despite that, the tests failed.
Tests pass with 7.1.1 and 7.3.3
* 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
* Add appStore option
* Fix "--app-image" option
* Add appCategory option
* Document signing for the Apple App Store
* Fix system version in the Product Definition Property List
* fixup! Fix "--app-image" option
* fixup! Document signing for the Apple App Store
* fixup! Add appStore option
* fixup! Add appCategory option
* Add provisioningProfile option
* Add entitlementsFile option (needs to be customised if your Mac app uses entitlements not in the default file)
* 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
* move to kotlin 1.6.10-RC and corresponding compose commit
* Update path to the karma plugin we are patching
* Add ExperimentalComposeWebStyleApi
what worries me that this actually shows that there are some cases where without any changes apart version compiler people will have to worry about such annotations
* update kotlin version in templates to adopt 1.6.10-RC
* web: move ComposableWithNullableTypeParameter.kt to passing test cases
* update kotlin version in other places
* update imageviewer example: add OptIn for experimental API
* move compose
* move to kotlin 1.6.10 and corresponding compose
* move to kotlin 1.6.10 and corresponding compose
* move to 1.0.1-rc2
* move to 1.0.1-rc2 (todoapp)
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
Co-authored-by: Shagen Ogandzhanian <shagen.ogandzhanian@jetbrains.com>
Remove:
```
__LATEST_COMPOSE_RELEASE_VERSION__
__KOTLIN_COMPOSE_VERSION__
System.getenv("COMPOSE_TEMPLATE_COMPOSE_VERSION")
```
They pollute templates/examples.
Now, all paths where we need to change the version are hardcoded in the script.
Usage:
```
./replace.sh 1.0.0-rc6
```
This script is planned to run on CI
In the future I will add support for changing Kotlin version
Alexey Tsvetkov
Igor Demin
Blaž Šolar
dima.avdeev
Nikita Lipsky
Omico
Oleksandr Karpovich
Oleksandr Karpovich
Philip Wedemann
Thomas Vos
Abdelilah El Aissaoui
Gabriel Souza
Louis CAD
Alexey Tsvetkov