* Move source artifacts to KotlinVariant classes (since joint Android
variants may have multiple source artifacts, make it a set)
* Change lowerSpinalCaseName to dashSeparatedName (doesn't transform
the strings to lower case inside)
* Don't transform the project name to lower case (in the future, it may
be reasonable to stop transforming the target and component names, too)
Still transform the target names and the component names.
Currently, this is the way we don't break existing publications and may
still reconsider this in the future.
* Add a workaround for a list of GString's assigned to
publishLibraryVariants
* Check for Android library variants existence in a more strict way,
report existing variants that are not library variants.
As KotlinCompilation only contains the directly added source sets in its
`kotlinSourceSets` property, we need to provide a convenient way to
collect the whole source sets hierarchy for a compilation.
We added internal `allKotlinSourceSets` some time ago, and it seems
reasonable to expose it as public API.
Issue #KT-28749 Fixed
Instead of exposing a single `component` in a target, allow it to have a
set of `components`, then create a Maven publication for each of the
components.
Move `createUsageContexts` to private API since a target that has
multiple publications may need to create the usage contexts for those
publications differently.
Move some of the components technical stuff to interfaces
`DelegatedToPublication` and
`ComponentWithCoordinatesDelegatedToPublication` in order to reuse it
later for Android's components.
Make compiler plugin options evaluate lazily, with Lazy<String> and
FileCollection as replacements for the eagerly-evaluated data.
Adjust compiler plugin option usages so that their evaluation is not
triggered when not necessary.
Issue #KT-26065 Fixed
Gradle has a function `attributes { ... }` for `Configuration`, so we
can introduce one, too, for uniformity of the DSLs. This will configure
the `val attributes: AttributeContainer` of the `KotlinTarget` and
`KotlinCompilation`.
Issue #KT-27682 Fixed
* Add DSL for project(...) with path and configuration
* Add DSL for e.g. api(someDependency) { /* ... */ }
* Add DSL for e.g. api(kotlin("stdlib"))
Issue #KT-26663 Fixed
As Gradle Groovy DSL does out-of-the box not allow working with
SAM-receiving functions in the same way as those accepting a Closure,
and, moreover, does not work with Kotlin default parameters, we need
to provide Groovy-friendly DSL functions along with Kotlin DSL functions
This commit adds those additional members for all of the newly
introduced MPP DSL members.
Previously, the connection between a `KotlinCompilation` and its
default `KotlinSourceSet` (the one automatically created and added into
the compilation) was not expressed in the MPP model in any reasonable
way that can be used in the build scripts.
However, this connection seems to have settled in the build logic, and
it may be useful to be able to get the default source set from a
compilation, for example, to be able to configure dependencies across
several targets in a uniform way.
The metadata compilations don't have their dedicated source sets, but
we can think of commonMain as a default source set for the project's
metadata, is it is currently in fact only contains the declarations from
commonMain.
Issue #KT-27685 Fixed
To simplify configuring a `KotlinCompilation` with Gradle Kotlin DSL, it
is essential to expose statically-known types where possible.
This commit parametrizes `KotlinCompilation` with its Kotlin options
type (a subtype of `KotlinCommonOptions`) and adds `kotlinOptions` and
`compileKotlinTask` to `KotlinCompilation`.
(minor) Also reduce the visibility of `attachClassesDir` and
`setupPlugins` to internal, since this API is not for external use.
This new interface uses a more general type for its kotlinOptions,
KotlinCommonToolOptions rather than KotlinCommonOptions. This is
needed for the Kotlin/Native task to implement a common interface
with the other Kotlin compilation tasks.
* Pull the `targets` and `presets` properties of the `kotlin` extension
up to an interface in `kotlin-gradle-plugin-api`
* Generate the code: we need type-safe statically-typed functions for
different target type, which seems to be only possible to achieve by
providing a function per preset.
* Place these functions in the top-level `kotlin` Gradle extension,
rather than extension functions for `kotlin.targets`:
- `kotlin.jvm { ... }` will work, while `kotlin.targets.jvm { ... }`
won't, the extension function needs to be somehow brought into scope
- reducing the nesting level by one seems to be a good move here
Issue #KT-26389 Fixed
Add the corresponding Gradle plugin DSL, consistency checks, and logic
for propagating these settings to the compiler during build.
Issue #KT-26840 In Progress
Remove the implementation of the `FileCollectionInternal` interface in
`KotlinCompilationOutput`. This interface may change unexpectedly (and
does between Gradle 4.10 and 5.0) so we need to get rid of its
implementation.
On the other hand, we can't just implement `FileCollection` instead
because Gradle internally assumes that all `FileCollection` instances
are also `FileCollectionInternal`. So the way to fix this is to remove
`SourceSetOutput` from superinterfaces of `KotlinCompilationOutput`
altogether.
Instead, to work with `SourceSetOutput` and `KotlinCompilationOutput`
in a uniform way, provide a wrapper for `SourceSetOutput`:
`KotlinWithJavaCompilationOutput` that is basically a proxy
class.
* To avoid unexpected effects from the Gradle instantiation mechanisms
for attribute values, use a safer String attribute type for the
KotlinPlatformType attribute
* Rename its entries to keep enum entries naming consistent
When a Kotlin metadata input configuration tries to resolve a module
with no Kotlin metadata (such as: plain old Maven module, a non-MPP
Kotlin project with a single platform), it should be able to resolve
successfully.
Given that the input metadata configurations extend from source set
dependencies configurations, where platform-specific dependencies may
occur, allowing the metadata configuration to resolve such dependencies
into platform artifacts seems to achieve successful dependency
resolution.
Issue #KT-26834 Fixed
Kotlin/JVM and Kotlin/JS use shaded compiler, but
Kotlin/Native uses non-shaded one.
Serialization plugin was configured to use either shaded or non-shaded
plugin version, because we used one configuration for resolving
compiler plugins.
This change introduces 'kotlinNativeCompilerPluginClasspath' configuration
for resolving Kotlin/Native compiler plugins.
In Gradle < 4.7, there's no `ComponentWithCoordinates` interface, and we
need to make sure that none of our classes implementing this interface
are loaded with older Gradle versions.
Instead of that interface, we can rely on Gradle's metadata generation
heuristic that takes Maven coordinates for the variants from the
corresponding publications.
After all MPP related changes, the `KotlinSourceSet` interface turns out
compatible with the old `KotlinSourceSet`, and, since there are external
usages of `KotlinSourceSet`, it is reasonable to expose the new
interface under the old FQ-name to fix those external usages.
Issue #KT-26498 Fixed
* Add dependency on KN shared in gradle-plugin
* Basic support for Kotlin/Native:
* Target presets
* Compilation into a klib
* Compilation into native binraies: framework and executable
* Basic dependencies between projects
* No jars in native publications
* Replace '-' with '_' in framework names
* Escape quotes in native command lines on Windows
* Move targets from Kotlin/Native repo
* Download KN compiler using Gradle's mechanisms
* Support source set dependencies in native
* Add configurations for consuming source sets metadata (extending the
source set's dependency configurations). These configurations will be
used by the IDE to pick up the dependencies metadata.
* Remove the universal preset from the default presets, create a
metadata target by default for compiling and publishing the metadata
of `commonMain` (in the future, we will publish and consume the
metadata of the other source sets as well).
* Make the classpath configurations of common modules consume the
metadata and thus ensure compatibility of 1.2.x MPP with the new MPP
model.
* Add a platform type androidJvm that is one-way compatible (can
consume but cannot be consumed) with jvm, register the matching
strategy
* Write our attributes to Android's output configurations (this uses
a naming convention that Android inherits from Java, but there's no
public API at the moment for that)
* Setup configurations' extendsFrom and inherit sources of source sets.
This make it unnecessary to restore transitive dependencies of a
source set at its use sites, since their sources and dependencies are
already included.
* Use dependsOn during default configuration instead of compilation.source()
Add default implementations for KotlinTarget and KotlinCompilation
(some of them are used in code added by further commits).
Refactor AbstractKotlinPlugin so that parts of its logic can be easily
applied outside the plugin (needed for MPP plugin later).
The single platform Kotlin plugins having Kotlin compiled along with
Java will now create a KotlinCompilation and a KotlinSourceSet per Java
source set or per Android variant.
The build configuration logic will use KotlinCompilation
objects rather than Java or Android plugin entities.
Subplugins API and implementations are updated to use KotlinCompilation.
1) Exclude the providers arguments from the kapt inputs, as the values
may contain absolute paths, may be output properties etc. The providers
should correctly annotate their inputs.
2) Fix the options passed to kapt as 'value=option' (leading to all the
options collapse into one with the null key), use 'key=option' instead
to make Kapt pass them as '-Aoption'.
Issue #KT-23866 Fixed
Issue #KT-25027 Fixed
Add 'kotlin.caching.enabled' flag to switch the caching for all tasks;
Rename and change semantics of cache support checks: make two instead
of one, `isBuildCacheSupported` and `isBuildCacheEnabledForKotlin`;
Remove FileOptionKind entries that are redundant at the moment;
Improvements in BuildCacheIT.kt and other refactoring suggestions from
the review
https://upsource.jetbrains.com/kotlin/review/KOTLIN-CR-1647
Introduce FilesSubpluginOption Special kind of SubpluginOption that
holds a list of files together with the kind of these files with respect
to the task.
Add a logic for handling such options and converting them into
task inputs.
Refactor CompilerPluginOptions: make it store subplugin options to be
able to add options from KotlinCompile to the kapt tasks.
Introduce WrapperSubpluginOption for encoded and complex options.
Remove pluginOptions from the Gradle inputs built from the
compiler args.
Do not cache Kotlin compilation with kapt1 enabled: since we are going
to drop kapt1 it anyway, there's no point in implementing
proper cache for it, so just disable the caching of the task in case
kapt1 is used.
Vyacheslav Gerasimov