* Don't set the localToProject attribute anymore, as it prevents proper
disambiguation if not set properly on all configurations, while all
the intentionally-public configurations
should already have the same value.
* Disambiguate o.j.k.platform.type Android vs JVM preferring JVM, as
Android should have other attributes which make pure-Android consumers
match the Android MPP variants.
* With Gradle 7.0+, set the attribute
`org.gradle.api.attributes.java.TargetJvmEnvironment` on the JVM &
Android elements configurations, which helps pure-Android consumers
to match the Android, not JVM variants. This fixes KT-30961 for
Gradle 7.0+ and AGP 7.0+
Issues: KT-49189, KT-30961
Apply generic (backend-agnostic) compiler plugin artifact instead of
Native-specific one when Native embeddable compiler jar is used
(with `kotlin.native.useEmbeddableCompilerJar=true` project property).
This partially reverts commit 2baf344f5f,
removing support for K/N embeddable compiler jar from subplugins.
More migration-friendly implementation is to be added instead.
Additionally to inheriting Gradle daemon arguments or configuring via
Gradle daemon arguments system property, it is also possible now
to configure arguments either using "kotlin.daemon.jvmargs" property
or extension DSL.
Extension DSL overrides special gradle property arguments, which
overrides Gradle daemon arguments.
^KT-45747 Fixed
* Always filter out the variant name attribute: it is never requested
by consumers, while its presence makes Gradle count it as an
unmatched attribute, sometimes leading to ambiguity;
* Filter out the build type attribute: if all variants have the same
build type, then remove the build type attribute from all variants;
Otherwise, remove the build type attribute from the release variants
in order to make them compatible with all other consumer's build
types.
* Add an opt-out flat for always keeping the attribute:
"kotlin.android.buildTypeAttribute.keep" Gradle property
Issue #KT-38954 Fixed
Limit use-case of UsesKotlinJavaToolchain interface to only Gradle tasks
and allow to query all tasks using
'taskContainer.withType(UsesKotlinJavaToolchain.class)'.
^KT-43095 In Progress
Add method into "kotlin" extension to set toolchain for all tasks.
This will also set toolchain for java compile tasks. Also user may
set toolchain via "java" extension and it will be applied to Kotlin
tasks as well.
^KT-43092 In Progress
Has to split jdk/toolchain setters, because, when toolchain setter is
in the 'UsesKotlinJavaToolchain', Groovy fails to create meta class
on <Gradle 6.7 with ClassNotFoundException.
^KT-43092 In Progress
Ensure that Gradle plugin dependencies do not include kotlin-stdlib,
kotlin-reflect and other dependencies that are provided by Gradle
runtime.
^KT-41142 Fixed
This is so that existing build scripts using
withType() do not break. Also, fix the failing
test.
It was necessary to keep outputFile for the js compile task
as it was accessed from the build scripts. Instead, a new
property is introduced which uses Gradle lazy properties.
This task input provides a way to set different from current Gradle
JDK and use it for Kotlin files compilation. By default it provides
current Gradle JDK.
Provided JDK major version is used as task input, so on providing
different JDK user will see cache miss.
All required interfaces are located inside api module.
^KT-45611 In Progress
As soon as JVM IR is enabled by default (in language version 1.5), use
the CLI argument `-Xuse-old-backend` or Gradle option `useOldBackend` to
switch to the old JVM backend.
The language/API version restriction here is to make sure the code works
with Gradle of earlier versions, but all versions of Gradle that we
support already depend on Kotlin 1.3+.
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.
Alexander Likhachev