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.
When Gradle resolves a dependency on a publication with no metadata
(or with metadata disabled), it represents it as two variants, one with
Usage `java-api`, the other with `java-runtime`. It turns out that the
`java-api` one does not contain transitive dependencies with Maven scope
`runtime`.
This commit makes the Kotlin Gradle plugin disambiguation rules behave
the same way as those defined in the JavaBasePlugin: when no Usage is
requested, prefer the runtime usages as they are more complete.
* Fix bugs causing early task evaluation
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
* Fix merge mistakes
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
* Fix another call forcing tasks evaluation Add a test for lazy tasks
Declare AnalysisFlags in module 'frontend', and JvmAnalysisFlags in
module 'frontend.java', to avoid leaking Java-related logic to common
compiler code
A KNPE happened because Gradle 4.7 (but not 4.8+) requested a
publication's dependencies before all other publications were created.
Issue #KT-27231 Fixed
Return the destination array instead of the destination storage array
wrapped in a new unsigned array. The difference should be
indistinguishable, however in JS, where inline classes are not inlined yet,
it had resulted in an extra wrapper.
The traditional Gradle/Java model assumes several configurations, which
are now deprecated, which are both `canBeConsumed = true` and
`canBeResolved = true`.
* compile, testCompile, etc.
* runtime, testRuntime, etc.
* default
These configurations need to somehow resolve correctly to an appropriate
platform-specific artifact when they contain an MPP library or project
dependency.
However, simply marking them with the Kotlin platform type attribute
would put these configurations under considerations during Gradle
variant aware depdendency resolution of project dependencies, which
in order would lead to ambiguity (e.g. `compile` vs `runtime` vs
`testCompile` vs ... vs `apiElements`).
To deprioritize these configurations during dependency resolution, we
mark them with a special attribute with a unique value in each project.
Given that the values are different in different projects, Gradle will
not choose a configuration marked by this attribute.
But we still need 'project(path: '...', configuration: '...')`
dependencies to work, and so, instead of rejecting those different
values of the attribute, we say that all values are compatible, but
when an ambiguity arises, choose the configurations not marked by this
attribute, so effectively eliminating them from resolution.
Issue #KT-27111 Fixed
* 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
* Add resources processing to the K/N compilations
* Use a proper resources output path (composed from target + compilation
rather than just compilation name)
* Fix incorrect reassignment of the resources directory
When a new MPP is published without Gradle metadata, the project
dependencies should be replaced with specific module dependencies,
e.g. `sample-lib` with `sample-lib-jvm`, because a consumer won't be
able to resolve `sample-lib` in a variant-aware way.
The following parts of the publications are affected:
* root publication
* with Gradle metadata, it is published and references the
other publications using the `available-at` mechanism
* without metadata opt-in, it is not published
* Kotlin metadata variant
* with Gradle metadata, it is added as an additional variant to the
platform-specific publications to allow the IDE to discover it
* without metadata opt-in, it is added as a dependency to the platform-
specific modules (like in old MPP)
These two will be needed when we publish a platform-specific part of a
MPP library in order to help the consumers of that single module
(rather than the whole MPP library) find the Kotlin metadata.
`KotlinVariantWithMetadataVariant` will be used for publishing with
Gradle metadata enabled, `KotlinVariantWithMetadataDependency` for
publishing without Gradle metadata, instead adding the Kotlin metadata
as a dependency, just like we did in old MPP.
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.
Sergey Igushkin