In the `KotlinPlatformType` disambiguation rule, don't prefer `common`
when there's a `jvm` or an `androidJvm` variant, as this would conflict
with disambiguation rules created by the other plugins, such as Gradle's
`java` which will choose `org.gradle.usage=java-api` and lead to
ambiguity.
Issue #KT-32239 Fixed
* If a KotlinGradleSubplugin implements
KotlinCompilerPluginSupportPlugin, don't apply it as a legacy plugin
* Add the legacy KotlinGradleSubplugin implementations back so that
when there's JAR hell with META-INF/services in the old artifacts
pointing to the classes, loading the plugins with ServiceLoader (legacy
implementation) from the new artifacts would not fail.
* There's a corner case for plugins not in kotlin-gradle-plugin
If a newer and older version of such a subplugin is used with an older
version of the Kotlin Gradle plugin, the latter will find the META-INF
entries and will try to load the subplugins from the new version. With
the original fix for KT-39809, this would result in silently ignored
empty stub implementations.
Given that the Kotlin Gradle plugin can now check if a subplugin
supports the new API, it's OK to keep the old entries and make the
stub implementations throw a build error when called, so that improper
plugin versions are not ignored and are clearly reported.
Note that this is only necessary for the subplugins not bundled in the
kotlin-gradle-plugin module, as those will always be in sync with the
Kotlin version.
Issue #KT-39809 Fixed
The old API was too specific for the Kotlin internal use cases and
leaked some abstractions due to the missing target-compilation project
model. One of such leaking abstractions was the Gradle tasks being
exposed to the subplugin, which required the tasks to instantiate
in order for the subplugin to apply. This violated task configuration
avoidance, so the old API could never work in compliance with TCA.
Introduce the new KotlinCompilerPluginSupportPlugin API that uses the
compilations instead of the tasks and is TCA-compliant.
Refactor the Kotlin/Native compilations and tasks to support
Kotlin/Native-shared source sets compilation within the metadata target.
Provide the feature flag kotlin.mpp.enableCommonKlibs that enables
the following behavior:
* compilation of Kotlin/Native-shared source sets to a klib using
the Kotlin/Native compiler.
* compilation of common source sets (not just Kotlin/Native) into a
klib rather than *.kotlin_metadata
Issue #KT-32677 Fixed
This patch adds a group of shortcut DSL methods allowing a user to
create simulator and device targets for Apple platforms along with
corresponding common source set(s) in one command. iOS, tvOS and
watchOS targets are supported.
Issue #KT-33856 fixed
As associated compilations will see internals of each other, they now
need to share the module name for the compiler to be able to correctly
generate calls to the internals.
Move `moduleName` to `KotlinCompilation`.
Group associate compilations into modules in a DSU-like way, use a
single module name for all of the compilations grouped into a module.
Add non-public API for the IDE to query additional visible source sets
for each source set.
Implement visibility inference via associate compilation links.
Implement visibility requirements for source sets and requirements
satisfaction checks in Gradle build.
Partial implementation of the associate compilations proposal. A
compilation can now contain links to other compilation that it compiles
against. This links will replace ad-hoc inter-compilation dependencies.
Issue #KT-34009 Fixed
* KotlinExecution
* KotlinExecutionSource
* KotlinTestRun
* Aggregating executions and execution sources
* KotlinTargetWithTests
* Add a `testableTargets` extension
* Make some Kotlin/Native targets testable (this requires
having a separate preset type for them)
* Implement test runs encapsulating the tests for all
existing testable targets by refactoring their
TargetConfigurator classes
Issue #KT-32679 Fixed
Sergey Igushkin