* 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.
Before the last change in this logic, the resources filtering used
the original Kotlin source directories, not those with Java filtered
out.
Make sure that the Java source directories that are added to the Kotlin
source set are excluded from the resources, and all the related
configuration works lazily, i.e. supports source sets modification
after configuration took place.
It was placed in the new MPP plugin and was therefore not used for
the 'KotlinSourceSet's with the old plugin. Move this logic to the
KotlinSourceSetFactory so that it is applied to all source sets
Otherwise this code behaves incorrectly on getter-only properties: it
returns a meaningless field signature whereas the property has no field.
It's hard to come up with an example of when this could matter in
compiler code, but it's very noticeable in kotlinx-metadata-jvm
#KT-26188 Fixed
This should have no effect on the correct code currently because all
properties have at least a getter, but may help in debugging problems
with serialized metadata for properties
* Set canBeConsumed = false only on those configurations that have this
flag according to the Gradle Java plugins. This saves us from breaking
existing build scripts but introduces ambiguity between consumable
configurations (e.g. between `apiElements`, `compile`, `runtime`). See
the solution in the next point.
* Don't set the Kotlin platform attribute on configurations that are
not meant for consuming in other projects or resolving directly. This
change hides these configurations from Gradle's variant aware
dependency resolution and therefore prevents ambiguity
(cherry-picked from 81f2c48f)
Moved SubpluginEnviroment to separate file and made public some methods
KotlinNativeCompile task now extends AbstractCompile so it could be passed to SubpluginEnviroment.loadSubplugins
KotlinNativeBasePlugin now declares kotlinCompilerPluginClasspath configuration
* 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()
* Parameterize with the target name and use it in the task names
* Get rid of separate task providers for common and js, use the default
with an appropriate target name
1. Kapt resolves runtime classpath during configuration, and because of
that we are unable to setup configurations that already took part in
dependency resolution. To fix that, run Kapt configuration as a separate
step out of the main loop over the variants
2. Old Android projects (< 3.0.0) don't have `api` and `implementation`
configurations. To stay compatible with those, ignore these
configurations being absent during configurations hierarchy setup.
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.
(Note: this commit leaves the repository in a non-compilable state as it
leaves some of the old API usages unchanged; they are replaced with new
implementations in further commits where more appropriate)
The new implementation covers the wider interface, and the factory
should now be used not on its own but in a named domain object container
(the API for creating a source set is now provided through the
source sets container rather than the factory, so that source sets are
also properly registered).
Introduce Gradle models for plugins 'kotlin-allopen', 'kotlin-noarg' and
'kotlin-sam-with-receiver'. Corresponding model builders are registered
in each one of those plugin main classes.
A Kapt model for Gradle projects including 'kotlin-kapt'plugin is
introduced. Its model builder KaptModelBuilder produces an
implementation of these models and can be queried through the Gradle
Tooling API when needed. Model builder is registered in
Kapt3GradleSubplugin.
A KotlinProject model for Gradle projects including Kotlin (JVM, JS or
common) plugins is introduced. Its model builder KotlinModelBuilder
produces an implementation of these models and can be queried through
the Gradle Tooling API when needed. Model builder is registered in the
corresponding Kotlin Gradle plugins.
Model definition should be published as a separate artifact in public
repositories so it can be consumed when needed.
Sergey Igushkin