tad
03/03/2023, 7:39 PMkotlin-tooling-metadata.json
matter for dependencies of an MPP project with only JVM/Android targets?afezeria
03/04/2023, 10:35 AMsdeleuze
03/04/2023, 2:08 PMMatt Nelson
03/05/2023, 9:06 AMfeatures
expression where consumers opt-in to a feature and the build system handles it.
Anyone know how I might best achieve this?hisham bin awiad
03/05/2023, 9:33 AMInstallation failed due to: 'Failed to commit install session 169461024 with command package install-commit 169461024. Error: INSTALL_PARSE_FAILED_MANIFEST_MALFORMED: Failed parse during installPackageLI: /data/app/vmdl169461024.tmp/base.apk (at Binary XML file line #139): com.common.broadcast.NetworkBroadCastReceiver: Targeting S+ (version 31 and above) requires that an explicit value for android:exported be defined when intent filters are present'
nkiesel
03/09/2023, 1:18 AMPablo
03/10/2023, 7:43 AMGradle Managed Devices
? I'm having some issues while running the Espresso
testsMarcus Cvjeticanin
03/10/2023, 4:27 PMinclude ("library-dir")
Will all of the includes get this? Or how can I do this if not? I just want to avoid writing the same config on several places.
Follow-up question regarding the publishing part:
• Should I have different versions of the libraries of my SDK? I saw that for example Ktor has the same versions for all libraries since they use a variable to define as $ktor_version
implementation("io.ktor:ktor-client-core:$ktor_version")
implementation("io.ktor:ktor-client-cio:$ktor_version")
Rasmus
03/11/2023, 10:10 AMcore/src/test/resources/logback-test.xml
?
To the relevant build directory of all of these submodules that depend on the core module:
submodule1/build/resources/test
submodule2/build/resources/test
...
Adam S
03/11/2023, 12:47 PMPHondogo
03/13/2023, 5:41 AMAdrian Witaszak
03/14/2023, 3:03 PMAdrian Witaszak
03/14/2023, 5:38 PMimplementation(project(path = ":AnyModule", configuration = null))
CLOVIS
03/14/2023, 9:44 PMkotlin("jvm")
, kotlin("js")
or kotlin("multiplatform")
. Is it possible to create a convention plugin that configures all of them? I don't want to create one plugin per Kotlin plugin…CLOVIS
03/16/2023, 6:56 PMCLOVIS
03/16/2023, 8:07 PMCould not create an instance of type org.jetbrains.kotlin.gradle.plugin.mpp.KotlinAndroidTarget.
> Could not generate a decorated class for type KotlinAndroidTarget.
> com/android/build/gradle/api/BaseVariant
The error message doesn't help me at all, where should I look for to fix this?Humphrey
03/17/2023, 6:22 AMhelpermethod
03/17/2023, 7:29 AMjava.toolchain
or kotlin.toolchain
in my build.gradle.kts
or both? What is the difference between the two?Gleb Minaev
03/18/2023, 11:11 AMidea { module { testSources.from(<path to the source directory>) } }
). But Kotlin source sets are not standard Gradle source set...
(Here is the use case.) I have a project with separate benchmarks source set. (Which is used in kotlinx.benchmark.) And benchmark tasks are marked as test ones. But the source set is not. So I want to "fix" the difference.CLOVIS
03/18/2023, 1:27 PMkotlin {
jvm()
android()
sourceSets {
val androidMain by getting {
dependencies {
implementation(platform(libs.androidx.compose.bom)) // Unresolved reference: platform
implementation(libs.androidx.compose.material3)
}
}
}
}
Mustafa Ozhan
03/20/2023, 1:31 PMlibs
from gradle/libs.versions.toml
in pre-compiled scripts located in buildScr/src/main/kotlin
?breandan
03/21/2023, 4:56 AMproperty = [...]
depends on collection literals): https://github.com/gradle/kotlin-dsl-samples/issues/324
Also related: https://github.com/gradle/kotlin-dsl-samples/issues/712Zac Sweers
03/21/2023, 5:07 AMhfhbd
03/21/2023, 1:36 PMObserableSet
and not using NamedDomainObjectSet
? 🤔Tianyu Zhu
03/21/2023, 7:56 PMbuild.gradle.kts
plugins {
kotlin("multiplatform")
application
}
application {
mainClass.set("path.to.my.MainKt")
}
kotlin {
js()
jvm()
}
I'd like to use gradlew run
to run the path.to.my.MainKt
file, but the run
task doesn't want to use the runtime classpath in jvmMain
. How do I fix this problem?Humphrey
03/22/2023, 4:07 PMid("jacoco")
in the plugins section of build.gradle I would like to use alias(libs.plugins.jacoco)
xxfast
03/23/2023, 10:39 AM// module-1 build.gradle.kts
plugin {
kotlin("multiplatform")
}
// module-2 build.gradle.kts
plugin {
kotlin("jvm")
}
// module-3 build.gradle.kts
plugin {
kotlin("js")
}
how do I enable explicitApi
mode for allprojects{}
of the root build.gradle.pks ?
// root build.gradle.kts
allprojects {
extensions.configure<KotlinMultiplatformExtension> { explicitApi() } // Extension of type 'KotlinMultiplatformExtension' does not exist.
}
Nigel Smith
03/27/2023, 9:47 AMgradle init
tries to convert but seems to miss the Kotlin plugin; picks up on some Java (mostly generated via Jooq) and creates only a java-conventions
file (so never actually tries to compile any of the kotlin) - does anyone know what that tool looks for to pick up on Kotlin in the pom?dave08
03/28/2023, 7:50 AMAlexandre Brown
03/28/2023, 7:27 PMsubprojects {
apply(plugin = "org.jetbrains.kotlin.jvm")
apply(plugin = "com.google.devtools.ksp")
repositories {
maven(url = "<https://repo.osgeo.org/repository/release/>")
mavenCentral()
}
...
dependencies {
implementation(project(":core:core-logging"))
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:$kotlinxCoroutinesVersion")
...
}
I have heard that using this approach is not recommended and that one should use buildSrc
instead.
I also use gradle.properties
to write the dependencies version : eg kotlinxCoroutinesVersion=1.6.4
but I am not sure if this is the recommended approach.
For Plugins I have the following in the root module (eg: backend:build.gradle.kts
):
plugins {
kotlin("jvm") version "1.7.21" apply false
kotlin("plugin.serialization") version "1.7.21" apply false
id("com.google.devtools.ksp") version "1.7.21-1.0.8" apply false
}
Then in the module that needs it I do the following :
eg: backend:backend-frameworks:build.gradle.kts
subprojects {
apply(plugin = "org.jetbrains.kotlin.plugin.serialization")
dependencies {
...
I would love some feedback and some pointers on how I should structure the dependencies using gradle recommended approach.
Some bullet points could help : eg: To share dependencies use ABC, to version dependencies use XYZ.
I'm pretty sure the way I set it up is not the recommended approach nowadays and I'm willing to change it.Alexandre Brown
03/28/2023, 7:27 PMsubprojects {
apply(plugin = "org.jetbrains.kotlin.jvm")
apply(plugin = "com.google.devtools.ksp")
repositories {
maven(url = "<https://repo.osgeo.org/repository/release/>")
mavenCentral()
}
...
dependencies {
implementation(project(":core:core-logging"))
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:$kotlinxCoroutinesVersion")
...
}
I have heard that using this approach is not recommended and that one should use buildSrc
instead.
I also use gradle.properties
to write the dependencies version : eg kotlinxCoroutinesVersion=1.6.4
but I am not sure if this is the recommended approach.
For Plugins I have the following in the root module (eg: backend:build.gradle.kts
):
plugins {
kotlin("jvm") version "1.7.21" apply false
kotlin("plugin.serialization") version "1.7.21" apply false
id("com.google.devtools.ksp") version "1.7.21-1.0.8" apply false
}
Then in the module that needs it I do the following :
eg: backend:backend-frameworks:build.gradle.kts
subprojects {
apply(plugin = "org.jetbrains.kotlin.plugin.serialization")
dependencies {
...
I would love some feedback and some pointers on how I should structure the dependencies using gradle recommended approach.
Some bullet points could help : eg: To share dependencies use ABC, to version dependencies use XYZ.
I'm pretty sure the way I set it up is not the recommended approach nowadays and I'm willing to change it.Vampire
03/28/2023, 8:24 PMI am looking for recommendation on how to structure it following the latest gradle recommendation (did not look into gradle for a while).https://github.com/jjohannes/idiomatic-gradle
I have heard that using this approach is not recommendedExact, practically any usage of
allprojects { ... }
or subprojects { ... }
is bad and instead convention plugins should be used. Whether you write them in buildSrc
or an included build or a standalone build that you publish doesn't matter and is totally up to you. I personally prefer an included build, or multiple.
I also useNope, the recommended approach is using a version catalog: https://docs.gradle.org/current/userguide/platforms.htmlto write the dependencies version : eggradle.properties
but I am not sure if this is the recommended approach.kotlinxCoroutinesVersion=1.6.4
Then in the module that needs it I do the following :Well, again - and here even more as it is in an intermediate project -
subprojects { ... }
is bad as it introduces project coupling and so prevents more sophisticated features like configure-on-demand or parallel configuration, besides that it makes builds harder to understand and harder to maintain.
And also requires to use the legacy way of applying plugins apply(...)
instead of using the recommended plugins {... }
block.Alexandre Brown
03/28/2023, 8:26 PMVampire
03/28/2023, 8:31 PMtask("...")
, no tasks.withType<...> { ... }
, no tasks.getByName(...)
, only very conservative tasks....matching { ... }
if at all, no tasks.create
, ...
https://docs.gradle.org/current/userguide/task_configuration_avoidance.htmlAlexandre Brown
03/28/2023, 8:32 PMextensions.getByType<KspExtension>().apply {
arg("mockative.stubsUnitByDefault", "true")
}
But I will try to minimize such cases, thanks!Vampire
03/28/2023, 10:14 PMconfigure<KspExtension> {
arg("mockative.stubsUnitByDefault", "true")
}
(yes, without extensions.
)tasks.withType
, withType
!= getByType
.
And also while you can follow the same rules for all containers (always using bla.register
, not bla.create
and so on, it is currently mostly relevant for task collections.
As far as I know no other collection is really used lazily yet, so while more future proof, it is not tragic if you don't follow the rules on them.
And besides that, tasks.withType<...>().configureEach { ... }
is fine, that is lazy.
But tasks.withType<...> { ... }
is bad as it would always realize and configure all tasks of that type whether needed or not.
(don't ask why, this is because the bad API was there before the task configuration avoidance approach, so it cannot change its meaning easily)