* The members of Result are isSuccess, isFailure, exceptionOrNull, getOrNull
* The rest of API is implemented via inline-only extensions
* There are two internal functions to hide detailed mechanics of an internal
Result.Failure class: createFailure and throwOnFailure
* Result.toString is explicit: either Success(v) or Failure(x)
See KT-26538
Split import handlers into multiple files
Add empty Maven handler for Android Studio
Add testRuntime dependency on kx-serialization-plugin for all modules which require compiler
plugins in test classpath
Updated version to 0.5.1
Fix resolving serializers for classes from other modules
(Kotlin/kotlinx.serialization/153)
Respect @SerialName on classes
Add support for @SerialInfo on class-level
Fixed issue when serialDesc property getter was generated, but backing field not.
Respect @Serializable(with=...) on property
Calling 3-arg readElementValue for support of custom contexts
Ability to nest context-based serializer
Migration to 1.2-Beta2
Use polymorphicSerializer prior to default
Don't use polymorphic serializers for all java classes
Docs and maven project update
Remove plugin runtime dependency on stdlib
- Move experimental coroutines out of the main source root.
- Include experimental coroutines into the coroutines source set.
- Include release coroutines into the main source set.
* Generate the JARs with the same names as they are published.
Put the target name in the JAR name's appendix instead of classifier.
* Configure Maven publications eagerly to allow their editing by user.
* Take KotlinVariant's coordinates from the MavenPublication.
If the user changes Maven coordinates of the publication, this ensures
the parent component to have the updated information.
In Gradle < 4.7, there's no `ComponentWithCoordinates` interface, and we
need to make sure that none of our classes implementing this interface
are loaded with older Gradle versions.
Instead of that interface, we can rely on Gradle's metadata generation
heuristic that takes Maven coordinates for the variants from the
corresponding publications.
In new MPP, add source sets taking part in more than one compilation to
the tasks' `commonSourceSet` in order to pass them as -Xcommon-sources
Issue #KT-26515 Fixed
* Some of the usages of `kotlinSourceSets` should instead get all the
source set from the source set hierarchies, i.e. including the ones
transitively-participating in the compilation
After all MPP related changes, the `KotlinSourceSet` interface turns out
compatible with the old `KotlinSourceSet`, and, since there are external
usages of `KotlinSourceSet`, it is reasonable to expose the new
interface under the old FQ-name to fix those external usages.
Issue #KT-26498 Fixed