The entire concept of conventions is deprecated in Gradle. The proposed alternative for `BasePluginConvention` is `BasePluginExtension`
^KTI-1473 In Progress
It's going to be deprecated in Gradle 8.3
There's currently no way to pass a `org.gradle.api.provider.Provider` to the JavaExec.systemProperty or Test.systemProperty. There's a workaround using `org.gradle.process.CommandLineArgumentProvider`, but I intentionally don't rework these calls as Gradle is going to allow passing providers to configure system properties: https://github.com/gradle/gradle/issues/12247#issuecomment-1568427242
^KTI-1473 In Progress
slf4j libs are bundled unshadowed to main-kts jar to avoid annoying
slf4j stderr printout (slf4j is used in the maven dependencies resolver)
Exluding it from proguard processing solves problems with using it
directly from scripts.
#KT-60813 fixed
#KT-54819 fixed
The -all jar is compacted with proguard, and the proguard removes
synthetic methods methods with $default suffix from classes regardless
of the -keep flag.
Therefore the calls to the $default metods lead to the NoSuchMethodError
exception on runtime.
Removing the main interface module from the proguarded jar solves the
problem for now (but not generally, the use of "proguarded" jars as
libraries should be discouraged.)
#KT-60862 fixed
Review: https://jetbrains.team/p/kt/reviews/6753
Meaningful semantic change was splitted into 5 commits to simplify the
change review. Sinle commit would be too big.
Why replace source to binary: to get rid of kotlin-reflect in Kotlin
plugin artifact KTIJ-22276
Note: Kotlin Maven artifacts (./gradlew publish) changed their
dependency on kotlin-reflect
This exception is happening on build configuration trying to remove
default jar task artifacts from published one. I've set 'jar' task
to be always disabled instead and just add shadow jar to artifacts.
the dependency on the coroutines library caused various problems like
KT-30778, or stdlib/runtime version conflicts.
The only function used was `runBlocking`, so this change replaces it
with the internal implementation based on the similar internal thing
from the stdlib.
#KT-30778 fixed
Use {de,}capitalizeAsciiOnly and to{Lower,Upper}CaseAsciiOnly where
possible, and stdlib's functions with Locale.US everywhere else.
Otherwise, if the default system locale is Turkish, the capital latin
letter "I" is transformed in toLowerCase to "ı" (see
https://github.com/JetBrains/kotlin/blob/66bc142f92085047a1ca64f9a291f0496e33dd98/libraries/stdlib/jvm/test/text/StringJVMTest.kt#L119),
which for example breaks the codegen for `intArrayOf` in
KT-25400/KT-43405.
Similarly, lower case latin letter "i" is transformed to "İ".
#KT-13631 Fixed
#KT-25400 Fixed
#KT-43405 Fixed
#KT-38404 fixed
also:
- Add wrapper class for the location combined with the location id
- Add source code location parameters to external dependency resolvers
- Add tests for locations in annotations
- Add tests for order of annotation resolution for dependencies resolvers
it conflicts with the compilation on daemon, so transistion should
be planned accordingly, and now it is not a good time for it.
The most important part of the renaming remains intact.
Partially reverts commit "Rename scripting libs and plugin - invert embeddable suffix"
now regular, unshaded libs, are named with suffix `-unshaded`, while
former `-embeddable` ones named without any suffix. This will encoursge
use of the shaded libs by default, avoiding conflicts with 3-party
libs packed into the `kotlin-compiler`.
Note, that only the "frontline" libs are renamed to avoid switching
problems, the ones that not normally used directly are left as is,
including the `kotlin-compiler` itself.
so it is possible now to create custom host configuration with template
and all configurations are handled consistenly.
Also introduce and use new ScriptDefinition class wrapping compilation
and evaluation configurations, that could be consistenly created from a
template.
Exclude jdk files form libraries input. Instead add jdk major version
to inputs. JavaCompile task acts same to ignore fluctuations in JDK
implementations since api should remain same
The relocation root different from the one in embeddable compiler
lead to "linking" errors for classes included in both jars, e.g.
Disposable. Reuse common root to avoid it.
cristiangarcia