* Adjust some of the test tools to work with *.kts scripts
* Expose the tool for version substitution into plugins DSL and use it
* Transform the lib-and-app test case to Gradle Kotlin DSL
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
1. Use 'KaptOptions' for all kapt options, including paths and flags.
2. Use a single 'KAPT_OPTIONS' compiler configuration key for setting all options (using a mutable KaptOptions.Builder).
3. Pass 'KaptOptions' instead of separate flags.
4. Remove 'KaptPaths'.
5. Remove deprecated 'aptOnly' CLI option.
'ServiceLoader' in JDK8 leaks file handles (https://bugs.openjdk.java.net/browse/JDK-8156014).
New implementation uses the ZipFile API, it also doesn't operate on the whole classpath which is not often needed.
It was once needed for the compiler plugins bundled straight into the compiler (read: kapt1). Since there are no bundled plugins anymore, the parent-last plugin classloader itself is not needed anymore.
Sergey Igushkin