When a non-Kotlin (JVM) project resolves an MPP library dependency,
it expects only one variant per Java Usage value ('java-api',
'java-runtime-jars'). If there's more than one, it will report
ambiguity and fail.
So we need to avoid creating non-JVM variants with Java Usage values
to ensure that non-Kotlin consumers can resolve the dependencies on
an MPP library with a single JVM target (if there's more than one
JVM target, there will still be ambiguity, but that's quite what one
would expect and what can be solved with custom attributes).
Instead, we define two Kotlin-specific Usage values, 'kotlin-api' and
'kotlin-runtime', so that:
* input configurations with these Usage values can consume plain Java
artifacts, for compatibility with plain old Kotlin modules
* if a consumer does not request a Kotlin usage and receives the two,
let it use the runtime one as it is more complete
We then use the two Usage values on those Kotlin input and output
configurations which are not JVM-related, and leave the Java Usages
for the JVM targets.
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
Instead of simply adding all Kotlin source sets participating in an
Android compilation, as was appropriate until we introduced the
dependsOn relation, we should now build a proper source sets hierarchy.
Compare type-aliases by it's fqNames instead of identity, as
multiple runs of resolveToDescriptorIfAny produces different descriptors
for one declaration
Android Studio idea.jar is taken from clion projects and has
IdeSpecificFeatures.xml and ProductivityFeaturesRegistry.xml files that
mention function that have to be found in ProductivityFeaturesRegistry.
Unfortunately, correspondent CLion bundle is not registered in tests, and
this causes a lot of tests fail.
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.
Drop KotlinJUnitRunConfigurationProducer, KotlinRunConfigurationProducer
bunch files
Extract differences in behaviour to 'jvmMppUtils.kt'
Improve 'isConfigurationFromContext' checks for 181 and as32
(this prevents duplicate configurations being created)
KotlinRunConfigurationProducer chooses corresponding jvm module
for common code
#KT-26886 Fixed
Sergey Igushkin