The `*Api`, `*Implementation`, `*CompileOnly`, and `*RuntimeOnly`
configurations of a `KotlinSourceSet` must not be resolved directly, as
they lack attributes needed to choose a Kotlin MPP variant, and they
must not be candidates in variant-aware resolution of a project
dependency either.
With Gradle 5.3, these configurations failed to resolve anyway, as they
had no proper `org.gradle.usage` attribute, and the disambiguation
rules of the 'java-base' plugin conflicted with the Kotlin rules.
In Gradle 5.3, there was a change to the internal logic of publishing
`SoftwareComponent`s with the 'maven-publish' plugin, and,
simultaneously, a new public API was introduced for user-defined
software components, see https://github.com/gradle/gradle/pull/8399
Earlier, the 'maven-publish' plugin used the Gradle `Usage` attribute
values to arrange the dependencies of a software component's
`UsageContext`s into the Maven scopes. Now that mechanism doesn't work
and a `SoftwareComponent` must provide an explicit mapping of the
variants to POMs by using the `SoftwareComponentFactory.adhoc` API.
However, the new API lacks some features we need to properly publish an
MPP, such as adding a component to another one as a variant, so we still
create old-style software components under the hood and
then wrap them into the new API (and then wrap the adhoc components once
again).
We also continue to use the old-style components for Kotlin-specific
logic like finding a target in another project that a dependency
resolved to, as the components produced by the new API lack crucial
information that is used in the logic, like references to
`KotlinCompilation`s.
Issue #KT-30379 Fixed
The support on our side involves:
* using the new value for Maven publishing, as the 'maven-publish'
plugin now expects 'java-api-jars' for dependency scopes ordering where
it used to expect 'java-api'
* accepting the new value in KotlinUsages compatibility and
disambiguation rules
In Android projects we need to detect modules by inspecting jar files
in order to find build history files.
However `useModuleDetection` property was not set up correctly for
KaptGenerateStubsTask.
#KT-29761 Fixed
Provide UArraysKt class in kotlin.collections for binary compatibility
instead of removed multipart facade class. It contains only non-inline
functions of the latter.
In Kotlin/Native 1.3.30 EAP1 an ability to build
a static ObjC framework has been added. This patch
adds support for this feature in the kotlin-multiplatform
plugin.
This patch adds a separate Gradle plugin allowing
a user to import Kotlin/Native modules in Cocoapods
projects and use Cocoapods dependencies in Kotlin
code via cinterop.
The plugin when applied does the following things:
1. Add a framework binary for each supported (iOS
or macOS) platform in the project.
2. Add a Cocoapods extension allowing one to configure
Cocoapods dependencies of the project.
3. Create cinterop tasks for each dependency from the
previous point. The tasks are added for main
compilations of each supported platform.
4. Add a task to generate a podspec-file which includes
the framework from the point 1, script to
build it and dependencies from the point 2.
So the Cocoapods import procedure is the following:
1. A user runs `./gradlew generatePodspec`. The plugin
creates a podspec-file with all dependencies.
2. The user adds a dependency on this podspec in his Podfile
and runs `pod install`. Cocoapods downloads dependencies
and configures user's XCode project.
3. The user runs XCode build. XCode builds dependencies and then
runs Gradle build. Gradle performs interop processing and
builds the Kotlin framework. Compiler options and header
search paths are passed in the Gradle from XCode environment
variables. After that the final application is built by XCode.
Issue #KT-30269 Fixed
Earlier we used to have two methods: cinterops(Container.() -> Unit) and
cinterops(Action<Container>). It's OK for Groovy DSL but causes resolution
ambiguity in Kotlin DSL. This patch removes the first overload to avoid
this situation. The second overload still can be called in Kotlin DSL
as `cinterops { ... }`.
Ilya Gorbunov