louiscad
06/15/2019, 2:02 PM1.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…Dominaezzz
06/15/2019, 3:17 PMlouiscad
06/15/2019, 10:04 PMgildor
06/16/2019, 6:16 AMlouiscad
06/16/2019, 9:38 AMgildor
06/16/2019, 11:35 AMlouiscad
06/16/2019, 2:41 PMmsink
06/16/2019, 4:52 PMlouiscad
06/16/2019, 5:30 PMgildor
06/17/2019, 12:05 AMlouiscad
06/17/2019, 8:23 AMgildor
06/17/2019, 8:53 AMlouiscad
06/17/2019, 9:07 AMgildor
06/17/2019, 9:08 AMlouiscad
06/17/2019, 9:10 AMVasily Levchenko
06/17/2019, 9:17 AM1.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#L126louiscad
06/17/2019, 11:01 AMgildor
06/17/2019, 11:02 AMlouiscad
06/17/2019, 11:04 AMgildor
06/17/2019, 11:05 AMlouiscad
06/17/2019, 11:05 AMgildor
06/17/2019, 11:05 AMlouiscad
06/17/2019, 11:07 AMgildor
06/17/2019, 11:08 AMlouiscad
06/17/2019, 11:09 AMBUILD SUCCESSFUL in 29m 49s
552 actionable tasks: 416 executed, 136 up-to-date
gildor
06/17/2019, 11:30 AMlouiscad
06/17/2019, 11:52 AMpublishLibraryVariants("release")
from somewhere but forgot to put it in new buildSrc code while trying to simplify the logic and supporting Kotlin/Native targetsgildor
06/17/2019, 2:16 PMlouiscad
06/17/2019, 2:34 PMVariant 'android-releaseApiElements' capability com.louiscad.splittiessplitties fun pack android base with views dsl3.0.0-dev-015:
- Incompatible attribute:
- Required com.android.build.api.attributes.BuildTypeAttr 'debug' and found incompatible value 'release'.I'm not sure how I can fix this. I want to publish the release variant only.
russhwolf
06/17/2019, 2:59 PMlouiscad
06/17/2019, 3:00 PMrusshwolf
06/17/2019, 3:00 PMlouiscad
06/17/2019, 3:04 PMh0tk3y
06/17/2019, 3:13 PMlouiscad
06/17/2019, 3:19 PMartifactId
(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?h0tk3y
06/17/2019, 3:35 PMpublishLibraryVariantsGroupedByFlavor = 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?louiscad
06/17/2019, 3:41 PMmavenPublication { … }
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"
h0tk3y
06/17/2019, 3:47 PMrelease
build type, but not for the debug
one. Use publishLibraryVariants("release", "debug")
and publishLibraryVariantsGroupedByFlavor = true
to publish both of them within one module.louiscad
06/17/2019, 4:22 PMh0tk3y
06/17/2019, 4:30 PMdemo
, 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.louiscad
06/17/2019, 4:57 PMpublishLibraryVariantsGroupedByFlavor = true
, but now, the IDE no longer navigates to source (for Android variant), showing only compiled class file, even for Android sources only modules… I didn't have the issue on previous versions. Is there a way to fix this?.module
files, so the .pom
files were used, and we could call it a day. Now with the maven-publish
plugin, the module.json
file that restricts the variant down the consumer is taken to its final form with the .module
extension, even for Android libraries, and is uploaded to bintray.
I didn't find the .module
files being part of the artifacts
of the MavenPublication
objects found in publishing { publications.withType<MavenPublication>() }
although I found the .aar
files, so I don't know how I can exclude them so they are not deployed to mavenLocal, nor bintray (BTW, that explains why mavenLocal didn't work for me after I moved to MPP library publishing).
Do you know how I can exclude these files, or if that is a feature that could be added to the Kotlin multiplatform gradle plugin when dealing with android libraries?h0tk3y
06/17/2019, 9:19 PMenableFeaturePreview("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.louiscad
06/17/2019, 9:51 PM.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