Re-implement `whenEvaluated` using a constant number of calls to
`withPlugin` per project.
The approach with `plugins.all { ... }` introduced by the fix
of KT-50509 had an issue with Android plugins applied last in the build:
in those cases that implementation didn't dispatch the actions after
Android and instead fired them earlier in `afterEvaluate`, because
`hasPlugin` doesn't return true in the callback when that exact plugin
is applied.
This change preserves the performance similar to that of the previous
implementation.
Issue #KT-50736
Merge-request: KT-MR-5418
The Android unit test tasks were not created by the Kotlin Gradle
plugin, so the plugin didn't add the
tadk dependencies to its aggregating
`allTests` task.
Issue #KT-38456
Issue #KT-44227
... to access `KotlinMultiplatformExtension` on subprojects.
This will prevent strange ClassCastExceptions and show users
a proper error message when the operation fails because of isolated
classpaths.
This will also be lenient if the isoalted Kotlin plugin is not
a multiplatform plugin.
^KT-50592 Verification Pending
Using this special cast function for accessing any Kotlin extension
will ensure that an isolated classpath will be reported to the user
when the casting fails because of it.
^KT-50592 WIP
Using a different commonizer classpath is a very uncommon practice.
Checking the classpath for Gradle's UP-TO-DATE mechanism is
already misleading, because we are relying on a custom UP-TO-DATE
implementation that will not include this classpath anyway.
Removing this input is intended to improve commonizer startup time.
The Gradle API `pluginManager.withPlugin(id) { ... }` turned out to have
a significant performance footprint due to operations on underlying
immutable collections.
We can replace calls to `withPlugin` with checks of `hasPlugin` running
on each applied plugin.
Issue #KT-50509 Verification pending
to make it easier to add more tests in the next commits.
- Add unit tests for constants and inline functions
Also add tests for different kinds of Kotlin classes: CLASS,
FILE_FACADE, MULTIFILE_CLASS.
-Add unit test for nested classes
Also remove the existing integration test for nested classes to keep the
integration tests focused on the key scenarios while unit tests will
cover the corner cases.
Ignore inline functions that are private
Deprecation 'kotlin.coroutines' property and related
'kotlin.experimental.coroutines' extension DSL. These properties
are not doing anything since 1.5.0 release and has to be removed long
time ago.
^KT-50369 Fixed
Allows using different current Kotlin versions in benchmark.
For example, SNAPSHOT version when current branch is master and
dev version on CI build.
^KT-49921 In Progress
This reverts commit 6807ed6642.
The reason is that Kotlin compilers until and including version 1.6.10
have code that detects obsolete coroutines via these version
requirements (see `versionAndReleaseCoroutinesMismatch`). Since Kotlin
1.6.10 can read metadata of version 1.7, the earliest we can drop these
version requirements is Kotlin 1.8.0.
This template provides all infrastructure to write Kotlin scripts for
build regression benchmarks. These benchmarks will use gradle-profiler
to run provided scenarios on user projects. All benchmark results
in the script then will be aggregated into single one showing
difference between them.
Generally such kind of benchmarks should be used to track early Gradle
build regressions between releases.
^KT-49921 In Progress
After shadow is updated to 7.1.1, library ComponentsXmlResourceTransformer
should work fine.
The only reason for this patched version was the bug that was fixed in 7.1.0:
https://github.com/johnrengelman/shadow/releases/tag/7.1.0
^KTI-733 Fixed
Version 7.1.1 is absent in jcenter, so additional repository was added
in some modules.
Leave old version in NewMultiplatformIT.kt because of
`This version of Shadow supports Gradle 7.0+ only. Please upgrade.` error.
^KTI-733 Fixed
..to correctly pass the dependencies in the ExecuteKotlinScriptMojo.
#KT-50306 fixed
Also add a test that a script has access to plugin-configured
dependencies.
If plugin/dependencies is populated, the extra artifacts should be
made available when the script is run. This test uses 'junit' simply
because it's commonly-used, but not already present, or shaded as part
of another artifact.
Dario Seidl