## Proposed changes
1. Added support to join JARs to the uber JAR with ProGuard, disabled by
default:
```
compose.desktop {
application {
buildTypes.release.proguard {
joinOutputJars.set(true)
}
}
}
```
2. All 'release' tasks now really depend on ProGuard, as stated in
[tutorial](https://github.com/JetBrains/compose-multiplatform/tree/master/tutorials/Native_distributions_and_local_execution#minification--obfuscation).
## Testing
- A new auto test
- Manual:
1. Test on Windows/macOs/Linux
2. Test the new Gradle parameter `joinOutputJars`:
```
compose.desktop {
application {
buildTypes.release.proguard {
joinOutputJars.set(true)
}
}
}
```
`false` (by default) should generate multiple jars (except for
`package*UberJarForCurrentOS`)
`true` should generate a single jar in a result distribution
3. Test debug tasks:
```
run
runDistributable
createDistributable
packageUberJarForCurrentOS
```
4. Test release tasks:
```
runRelease
runReleaseDistributable
createReleaseDistributable
packageReleaseUberJarForCurrentOS
```
The jars should be reduced in size (because Proguard is enabled in the
release mode)
This should be test by QA.
## Issues fixed
Fixes https://github.com/JetBrains/compose-multiplatform/issues/4129
---------
Co-authored-by: Igor Demin <igordmn@users.noreply.github.com>
Compose resources can be located in different KMP source sets in the
`composeResources` directory. For each resource an accessor will be
generated in the suitable kotlin source set.
The issue was in a case where there wasn't a direct dependency on the
skiko artifact, the task would attempt to get one at task execution
time. This moves that to task configuration time.
Users noticed if an app has big a `string.xml` file it affects the app
startup time:
https://github.com/JetBrains/compose-multiplatform/issues/4537
The problem is slow XML parsing.
Possible ways for optimization:
1) inject text resources direct to the source code
2) convert XMLs to an optimized format to read it faster
We selected the second way because texts injected to source code have
several problems:
- strict limitations on text size
- increase compilation and analysation time
- affects a class loader and GC
> Note: android resources do the same and converts xml values to own
`resources.arsc` file
Things was done in the PR:
1) added support any XML files in the `values` directory
2) **[BREAKING CHANGE]** added `Res.array` accessor for string-array
resources
3) in a final app there won't be original `values*/*.xml` files. There
will be converted `values*/*.cvr` files.
4) generated code points on string resources as file -> offset+size
5) string resource cache is by item now (it was by the full xml file
before)
6) implemented random access to read CVR files
7) tasks for syncing ios resources to a final app were seriously
refactored to support generated resources (CVR files)
8) restriction for 3-party resources plugin were deleted
9) Gradle property `compose.resources.always.generate.accessors` was
deleted. It was for internal needs only.
Fixes https://github.com/JetBrains/compose-multiplatform/issues/4537
# Changes
* Add `Never` to `enum class ResourceClassGeneration` to disable the
generation of Res class in the gradle plugin
# Motivation
As the [comment in issue
4229](https://github.com/JetBrains/compose-multiplatform/issues/4229#issuecomment-2008626808)
said, my team is not in the ecosystem of gradle, but organize the build
steps in bazel. We want to follow the files layout but just disable the
generation task of gradle and handle it by outself.
Steps to reproduce:
1) Add a 'font-en' directory with a font to an android app with compose
resources
2) build the app with `assembleDebug` and check that a corresponding dir
is presented in the final APK
3) rename a qualifier of the dir to `font-de`
4) re-build the app with the same command `assembleDebug`
Expected: the new APK will contain the new font dir
Actual: the new APK doesn't have the new font dir but has old one
'font-en'
The PR fixes that
- integrate KGP resource API
- packaging final resources to iOS and JS/Wasm applications
- integration tests of publication and multi module support
- info logging of supported Gradle and KGP versions
### requirements
- Kotlin Gradle Plugin >= 2.0.0-Beta05
- Gradle >= 7.6
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.
badmannersteam
Konstantin
Eliezer Graber
xzk
Oleksandr.Karpovich
dima.avdeev
Alexey Tsvetkov