As we introduced the 'api' configurations for Kotlin source sets, the
Java plugin did not link these configurations to its 'apiElements', and
those dependencies would only get published with the 'runtime' scope
through the 'implementation' configuration.
To fix this, manually specify that 'apiElements' extendsFrom 'api'.
Issue #KT-28355 Fixed
In Gradle 5.0, the 'prefer' function semantics has changed, and now a
transitive dependency version wins over the 'preferred' one. Instead,
'require' has been introduced in 5.0 with the old semantics.
Our users expect that the default Kotlin dependency version will be
at least as new as the plugin version, so we now need to use 'require'
with Gradle 5.0+
Issue KT-28820 Fixed
As non-Gradle consumers and Gradle consumers with metadata disabled
cannot read Gradle metadata, in POMs (the only source of dependencies
for the consumers mentioned above), we should publish the dependencies
on modules with metadata as the target artifact IDs rather than the root
MPP module ID (e.g. 'foo-jvm' rather than 'foo').
To do that, we rewrite the POMs of the publications even when Gradle
metadata is enabled. Note: in the POMs, a project dependency is already
written in the form of the artifact ID of the root Kotlin software
component, so it complicates the dependencies rewriting a little.
To rewrite third-party dependencies, we detect dependencies that
resolved to no artifact and have a single child in the Gradle
dependencies graph of the resolved configuration – this is what a
dependency looks like which was redirected to another module via
'available-at'.
Issue #KT-28482 Fixed
To configure a compilation's sources, we run an action in
`whenEvaluated { ... }`, expecting that the compilation's task already
exists. This was not true with compilations created from a user build
script or a 3rd-party plugin in `afterEvaluate { ... }`.
Fix this by expecting that a task may possibly not exist at that point,
and also using `whenEvaluated { ... }` instead of
`afterEvaluate { ... }` in several places that are executed for each new
compilation as a workaround for
https://github.com/gradle/gradle/issues/1135.
Issue #KT-28896 Fixed
Also update the code for rewriting the dependencies, as Android variants
have their dependencies configurations formed a bit differently, and
also introduce the logic for choosing the right component by the
configuration name the dependency resolves to.
Issue #KT-27535 Fixed
Move the logic of attaching a source JAR to a publication to the
components management part, as building a source JAR will be done
differently for Android.
Instead of exposing a single `component` in a target, allow it to have a
set of `components`, then create a Maven publication for each of the
components.
Move `createUsageContexts` to private API since a target that has
multiple publications may need to create the usage contexts for those
publications differently.
Move some of the components technical stuff to interfaces
`DelegatedToPublication` and
`ComponentWithCoordinatesDelegatedToPublication` in order to reuse it
later for Android's components.
Rewrite CharArray to String conversions to appending chars one by one.
Refine parameter checking in String(chars, offset, length) to adhere to
the common exception contract and document it.
#KT-29003
- Allow to select target platform and target directory to generate source for
- Put copyright profile to resources to have it in the resulting jar
- Output error for missing bodies, but do not stop generation on the first error
Sergey Igushkin