I'm seeing several multiplatform libraries publishing to bintray using version

1.8.4-jetbrains-5

of the bintray gradle plugin instead of the jfrog official 1.8.4 version. Why so? Didn't found any sources for it, nor any documentation regarding it…

Thank you, I now remember seeing this. I wonder why it's not documented anywhere while it's being used by several libraries, including kotlinx.coroutines. Also, the bintray page I found doesn't link to it (and no way to submit an issue for that on vvlevchenko's repo, it's disabled).

There is very important comment in issue 229 from Vasily. It looks that current solution is mostly hack and real fix would be reimplement gradle-bintray-plugin using new maven-publisg plugin than try to implement all new metadata publishing on top of existing implementation (my 2 cents that bintray plugin one of worst plugins that I saw when you work with Kotlin dsl, everything is dynamic)

You probably mean in PR 230, here: https://github.com/bintray/gradle-bintray-plugin/pull/230#issuecomment-456735555 I added a comment, looking for an example.

Yes, sorry PR 230 I did it once to avoid using bintray plugin. It's possible, but it requires generate all urls for bintray. Not sure that I still have this sample, will try to find

I'd be very interested. I'm currently working on setting up the Kotlin/Native sourceSets and targets nicely, with good IDE support, and nice usage from Gradle Kotlin DSL. I'd like to provide good base to make multiplatform libraries with ease.

It's working in my libui library - not iOS, but still - it uses Kotlin DSL and Gradle bintray plugin.

@msink I've checked out your project along with a few other ones (Stately, kotlinx.coroutines & SqlDelight), that has been helpful. I'm working on seamless sourceSets and targets activation and setup based on whether it's running in IDEA, and the current OS.

Yes, it working of course and it's nice that Kotlin DSL provides facilities to configure it, I just don't like it, and it was a small experiment to use pure maven-publish

Someone else replied to me a way to publish to bintray without the gradle bintray plugin: https://github.com/bintray/gradle-bintray-plugin/pull/230#issuecomment-502563195 @gildor Does that look like what you did?

Yes, exactly this

Hum, that might be possible as the bintray plugin has some config for versions. Please share if you find that back before I figure it out.

no-no, I mean version of the library (publication)

I found that blog post from Bintray themselves giving an exemple to construct the url: https://blog.bintray.com/2015/09/17/publishing-your-maven-project-to-bintray/

This

1.8.4-jetbrains-5

isn’t what is recommended to use. It was just the least effort to publish big bunch of artefacts without mass modification of build scripts. Recommended scenario is using

maven-publish

plugin even for bintray repository configured as repository of maven type. Here is a good example how to do it https://github.com/h0tk3y/better-parse/blob/fb2d5fb81b2a5eaccbe30419295f21ce1f70e5b0/build.gradle#L126

That's what I'm seeing as some artifacts are not published correctly. The maven-publish plugin seems ages slower than the bintray plugin though! It's at 43% uploading right now, after ~12 minutes executing while it took about 2 minutes to go to 100% with the bintray plugin. Correct is better than fast sure, but I'm wondering it you also encountered this.

I’m pretty sure it’s some bintray issue

Well, I have over a hundred of artifacts, so 2 minutes is the best I could get with optic fiber (60Mbps UP) 😅

how big each artifact is?

I'll leave the laptop there while I go to lunch, hopefully, publication usage will be successful.

I mean in general it’s just upload of files to storage

The artifacts are small, a few kilobytes (most only 1). I have about 40—50 modules, all with metadata and multiplatform publication. 3 of them target macOS, and all 3 iOS architectures, and 3 target JS IIRC

still shouldn’t be a problem (only if bintray is super slow)

oh, I spotted Jetbrains Toolbox having sent of 9GB of data 🤔 🤔 🤔

Did you enable parallel builds in Gradle? At least each module publishing should be parallel

So I'll have to wait for 5.5 to become available as 5.5 is still the one under RC.

A side note, waiting for official Android publishing support, it's shame that it took so long for Gradle to expose public API for this https://issuetracker.google.com/issues/37055147

Oh, after 4 years, it'll finally come in 3.6 soon™! 🙃

You might need to specify matching fallbacks in the consumer code https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#publishing-android-libraries

That is a less than nice burden added on the library consumers!

yeah I agree

It'd nice for it to just behave like jvm targets (using only the release variant). @h0tk3y Do you know how to properly publish only the release variant and have it just work on the consumer side?

AFAIK, you can't define the matching fallbacks on the producer side, as the matching fallbacks work by altering the attribute compatibility rules in Gradle variant-aware dependency resolution, and Gradle module metadata in published libraries can't include anything that would affect those compatibility rules on the consumer side. So the options are to publish the debug variant as well or to make the consumer specify the matching fallbacks, which is described here: https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#publishing-android-libraries

@h0tk3y this doesn't seem to work well with custom

artifactId

(defined in

mavenPublication { … }

called in

kotlin { … }

on the android target). Ideally, I'd want only one variant. Isn't there a way to just not have that variant-aware metadata, so it's possible to use the library in any variant with zero additional configuration for consumers?

You can try

publishLibraryVariantsGroupedByFlavor = true

, which will group all build types into a single module for each product flavor, so there's only one artifactId per flavor, and the module metadata will contain a variant per build type. However, this won't work for custom build types declared by the consumer which are not present in the published library. I'd say we can experiment with removing the build type attribute from the published variants, so that, on the consumer side, the variants are only matched by the product flavor, if any. The current implementation doesn't modify the attributes added by the Android Gradle plugin, because we just don't own those attributes. Could you please file an issue at https://kotl.in/issue?

With the following snippet, I'm configuring the

mavenPublication { … }

with a custom

artifactId

for each target (I call

configure(targets) { configureMavenPublication() }

in each

build.gradle.kts

). Am I applying your suggestion correctly?

fun KotlinTarget.configureMavenPublication() {
    val suffix = when (platformType) {
        common -> "-metadata"
        jvm -> ""
        js -> "-js"
        androidJvm -> ""
        native -> "-${name.toLowerCase(Locale.ROOT)}"
    }
    mavenPublication {
        val prefix = if (isFunPack) "splitties-fun-pack" else "splitties"
        artifactId = "$prefix-${project.name}$suffix"
    }
    if (platformType == androidJvm) {
        (this as KotlinAndroidTarget).publishLibraryVariants("release")
        this.publishLibraryVariantsGroupedByFlavor = true
    }
}

private val KotlinTarget.isFunPack: Boolean get() = project.parent?.name == "fun-packs"

No, because this way, the module will still only have a variant for the

release

build type, but not for the

debug

one. Use

publishLibraryVariants("release", "debug")

and

publishLibraryVariantsGroupedByFlavor = true

to publish both of them within one module.

How does grouping work? What is called "module" here? I'm not aware of a multi-variants module publishing method in maven and gradle world.

• An Android variant denotes the product flavor if any (

demo

,

paid

etc.), and the build type (

debug

,

release

). • With Gradle

maven-publish

plugin, each publication produces a Maven module with its own artifact ID. A module that is published with Gradle module metadata may contain more than one variant, each with its own artifacts and dependencies. • Without

publishLibraryVariantsGroupedByFlavor

, a publication is created for every Android library variant, such as

fooBarDebug

or

fooBazRelease

. Within each such a publication, there's only one variant. • With

publishLibraryVariantsGroupedByFlavor

, the variants are grouped by the product flavor, so that variants that only differ in the build type get published by a single publication (and are put inside as its variants). If you don't have any product flavors, this results in only one publication (i.e. one Maven module) that has a variant per Android build type. These variants are marked by the Android plugin's build type attributes.

May the android library publication story get simpler, allowing to publish without the variant metadata as the following issue is finally resolved in AGP 3.6? https://issuetracker.google.com/issues/37055147#comment12 Maybe there could be a collaboration with Google Android tools team?

@louiscad With Gradle 5.3+, the module metadata is always consumed from repositories, and the feature flag

enableFeaturePreview("GRADLE_METADATA")

only enables its publishing. If you don't want any module metadata to be published, you can just disable the feature. AFAIK, there's no more granular way to disable it with public API in Gradle.

@h0tk3y I just found a way to prevent the

.module

from being generated! Here's a type unsafe way (because

android

might be in the name without the task being for the android artifact):

tasks.withType<GenerateModuleMetadata>().matching {
    t.name.contains("android", ignoreCase = true)
}.all { enabled = false }

It works correctly. I wouldn't have found this technique if Google didn't led me there: https://github.com/gradle/gradle/blob/40a006b94b9cbfa4f9ed409f6f74b2828941cfd4/subprojects/maven/src/main/java/org/gradle/api/publish/maven/plugins/MavenPublishPlugin.java#L188