The EAP build is

1.3.20-eap-100

published to the Maven repo

<https://kotlin.bintray.com/kotlin-eap>

, here's how to apply it: https://discuss.kotlinlang.org/t/kotlin-1-3-20-early-access-preview/10748/10

Publishing Android libraries is disabled by default, to enable it, specify the list of the variants that you want to publish in the scope of the Android target.

kotlin {
    android { 
        // Or android("foo") { ... }, if you use a 
        // custom name for this target
        publishLibraryVariants("release", "debug")
    }
}

If you have no product flavors in the library, then it may be just the

release

variant. With product flavors, specify full variant names, like

fooBarRelease

. Publishing is only supported for library variants, not application or test variants. To publish all library variants, including the debug ones, instead call

publishAllLibraryVariants()

. If you publish several variants that share the product flavor and differ in the build type, like

fooBarRelease

and

fooBarDebug

, you may group them into a single publication by specifying

publishLibraryVariantsGroupedByFlavor = true

(false by default), then the build types become classifiers for the artifacts, and the

release

artifact is published with no classifier. Publishing is set up with the

maven-publish

plugin, which you also need to apply. The publications are created automatically, just as for other kinds of MPP targets, but you still need to setup the repositories for publishing, or publish to the local Maven repo. More details about

maven-publish

in the Gradle docs: https://docs.gradle.org/current/userguide/publishing_maven.html

Another change in the 1.3.20-eap-100 is how the dependencies are written in the POMs. Since POMs are only read by the consumers who can't read Gradle module metadata, the plugin will now always rewrite dependencies in the POMs, replacing each dependency on a multiplatform library with Maven coordinates of the actual target module that the dependency resolved to. For example, in a JVM target's POM, a dependency on a multiplatform library

foo

will be replaced with a dependency on the `foo`'s JVM module,

foo-jvm

. This will work for both project-to-project dependencies and dependencies on Maven publications. At this point, this only affects dependencies of multiplatform projects. We will likely expand this to single-platform modules in the future updates.

Also, a minor improvement is that a

KotlinCompilation

now exposes

allKotlinSourceSets

, which is a transitive closure of the source sets included into the compilation via the

dependsOn

relation, so you don't need to collect them manually.

Just regular multiplatform artifacts, not Android ones

for example this whole block doesn't work

it complains about missing

allJava

IIRC

I've tried every source ant tutorial which I could find but I couldn't make any of them work with

kotlin-multiplatform

that's why I think that a good tutorial or example project would be paramount

Having this plugin is useless if we can't use it with Maven Central

so right now I either use the old way which is really clunky

or just skip maven central altogether and use jitpack

but this is pretty lame in the long run as people expect to use maven central

sometimes outright reject anything else for good reason (https://blog.autsoft.hu/a-confusing-dependency/)

so JetBrains devs push things to Maven Central

so I think that it wouldn't be a big leap to publish a tutorial on how they do it

what I noticed is that the official JetBrains libs use the old way (not the

kotlin-multiplatform

plugin) which makes me think that it is not ready for prime time otherwise they would have been dogfooding it I presume

I'll try this one