Once set of dirty symbols is computed, filter these types
when they are requested from the JavaFileManager. This is accomplished
by tracking all declared types in the sources and generated sources.
It is not necessary track types in generated class files, as these will
be removed before the APs are incrementally run.
Motivation: APs (e.g. Dagger) may use Elements.getTypeElement(String)
to determine if type is already present, and if it is, they will not
generate it. Therefore, whenever generated sources is invalidated, types
it defines need to be filtered in the JavaFileManager.
Issue is https://youtrack.jetbrains.com/issue/KT-23880
Add support for incremental annotation processors in KAPT. These
processors conform to https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_annotation_processing
specification.
Support is provided by using javac compiler APIs and
recording the source file structure. At runtime, processors
are instrumented with custom Filer that is used to keep track of generated
files. In order to support classpath changes, stub generation task is
used to generated a list of changed FQCNs, and this is simply used by KAPT.
Both worker and non-worker mode are supported.
#KT-23880
As the Gradle Java plugin considers Java annotation processing cacheable
with any annotation processors, we can enable build cache by default
for Kapt tasks, leaving the opt-out flag just in case.
Issue #KT-27675 Fixed
When Android Java 8 desugaring is set as follows (or above):
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
set the Kotlin JVM target to 1.8
Issue #KT-21030 Fixed
This is the Gradle plugin that does not rely on the
Java model and uses the same Kotlin model
(target – compilation – source set) as MPP does.
Also add JS DCE support for this plugin.
Issue #KT-5756 Fixed
Issue #KT-13256 Fixed
Issue #KT-16355 Fixed
Issue #KT-20156 Fixed
Issue #KT-29284 Fixed
The attributes applied by the user to the target and its compilations
were ignored in single-platform plugins while the target was not a part
of the API.
Since the user will be able to access and configure the target, we need
to apply the attributes to the relevant configurations in the same way
as in MPP.
In MPP, the disambiguation classifier is always the same as the target
name. In single-platform projects, the task name suffix should be empty
for the JVM targets. Using the `disambiguationClassifier` for this
purpose is more consistent with other usages of
`disambiguationClassifier`.
The target name for all existing single-platform plugins will be just
'kotlin'.
Ensure that custom target and compilation attributes are copied to
relevant configurations of Android targets as well, which did not happen
because of Android variants (and missing simple apiElements,
runtimeElements) and Android compilations being created late in the
project configuration.
Issue #KT-27714 Fixed
As Android variants are created after the project is evaluated,
the build script and plugins might have added some item handlers to the
domain object containers which are yet to be filled.
To ensure that those handlers see properly configured compilations and
their tasks, we need to add a compilations to the container only after
it has been properly configured.
Also, the `forEachVariant` handler is already executed in
`afterEvaluate`, and there seems to be no need to wrap our
code working with variants in `afterEvaluate`.
Issue #KT-29964 Fixed
Previously we showed list of all deprecated APIs even if a user uses
only one of them. This patch changes the behaviour and shows only
APIs really used by the user. An approach similar to the one used by
SingleWarningPerBuild in applied here.
Issue #KT-29998 Fixed
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.
Alexey Tsvetkov