To enable parallel tasks execution within a project,
add 'kotlin.parallel.tasks.in.project=true'
to gradle.properties or local.properties file .
#KT-28155 fixed
It's less error prone to add/remove/reorder arguments this way,
because named arguments can be used and the compiler actually
checks that all arguments are passed to GradleKotlinCompilerWorkArguments's
constructor.
Exceptions were catched in `KotlinCompilerRunner.runCompiler`.
When the method from superclass is not used in
`GradleKotlinCompilerRunner`, the superclass does not make much sense
anymore, so I turned it into util object.
The class is used on both server and client, but it was defined in
server module.
Gradle plugin worked, because all classes are present in kotlin compiler
embeddable, but the code was red in IDE (which is correct because
Gradle plugin does not depend on daemon server module).
We want to be compatible with Gradle 4.0+
where the API is not available.
Use eager task creation API for now.
Lazy API support should be added later with
proper Gradle versions checks.
The existing disambiguation rule for the Usage attribute lead to
runtime variants being resolved even for compile-scoped input
configurations, because Gradle runs disambiguation rules even if the
consumer value is present in the candidates list.
For example, an `app` project's `jvmCompileClasspath` configuration
would get its `project('lib')` dependency resolved to the
`jvmLibRuntimeElements` instead of `jvmLibApiElements`.
Fix this by:
1) running the part of the disambiguation rule only with Gradle 4.1+, so
as to use the consumer value for proper disambiguation;
2) choosing the JAVA_API usage when the consumer is JAVA_API or
KOTLIN_API, and choosing one of the JAVA_RUNTIME usages if the
consumer is either KOTLIN_RUNTIME, one of the JAVA_RUNTIME usages, or
does not specify its usage.
Issue #KT-27849 Fixed
When a non-MPP is imported into the IDE, the importer anyway tries to
build the MPP source sets model, so it tries to access the
`compilerPluginArguments` and `compilerPluginClasspath`, resulting in
an import error.
Issue #KT-27646 Fixed
If a source set is used in only one compilation, take the options from
its compile task.
If a source set is used by multiple compilations of a single target,
either choose the 'main' compilation or choose any (this will happen
for Android, and it looks OK for the first time). If there are multiple
compilations of different targets, use the metadata compilation.
Issue #KT-27499 In Progress
Add the corresponding Gradle plugin DSL, consistency checks, and logic
for propagating these settings to the compiler during build.
Issue #KT-26840 In Progress
BuildOutputCleanupRegistry tracks the all of the outputs that belong to
the Gradle build, so when Gradle runs in an unknown state (e.g. without
any history), it can detect stale outputs in the output directories and
delete them.
Since this is an internal API, its usage is removed. Instead, another
way to tell Gradle that a set of directories belongs to the build is to
add them to the `delete` task targets.
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
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
Alexey Tsvetkov