Hey everyone, I'm creating a KMP library and want to publish it to my local Maven repository to add ...
h

heitorcolangelo

over 1 year ago
Hey everyone, I'm creating a KMP library and want to publish it to my local Maven repository to add this library as a dependency on an Android project. Here is the structure I'm using:
.
└── Library/
    ├── shared/
    │   ├── featureA (module)/
    │   │   └── build.gradle.kts
    │   ├── featureB (module)/
    │   │   └── build.gradle.kts
    │   └── src/commonMain/kotlin/com/example/library/
    │       └── Library.kt
    └── build.gradle.kts
The
shared/src/build.gradle.kts
depends on both
featureA
and
featureB
, and it also contains the publishing configurations, like below:
plugins {
    // Other plugins
    id("maven-publish")
}

group = "com.example"
version = "1.0"

publishing {
    repositories {
        mavenLocal()
    }
}

kotlin {
    androidTarget {
        // Other configs
        publishLibraryVariants("release")
    }
    // Other configs
    sourceSets {
        commonMain.dependencies {
            api(projects.shared.featureA)
            api(projects.shared.featureB)
        }
    }
}
After running the
publishAndroidReleasePublicationToMavenLocalRepository
gradle task, the artefacts are properly created, and I can add this dependency to my Android project, like below:
implementation("com.example:shared-android:1.0")
However, I can only access the classes that are inside
shared/src
and not the ones in
featureA
or
featureB
. Unless I also publish them as a separate library and import them into the Android project. What I expect is to publish a single artefact where I can access all the exposed classes/interfaces that are declared as
api
dependencies in the
shared/src/build.gradle.kts
Does anyone know if this is feasible?
I am writing a suspend-based wrapper around Caffeine's AsyncLoadingCache, which natively understands...
d

David Glasser

about 6 years ago
I am writing a suspend-based wrapper around Caffeine's AsyncLoadingCache, which natively understands cache-loading functions that return CompletableFutures. My class has a
get()
method which launches a coroutine using
CoroutineScope.future{}
. That coroutine should not be scoped to the
get()
method's lifetime, because if
get()
is called concurrently with the same key, both
get()
calls will end up waiting on the same CompletableFuture, so cancelling the first coroutine shouldn't cause the second coroutine to fail. So I'm currently passing a
CoroutineScope
into the constructor of the cache and using that to launch the `future`s. However, my current implementation means that if any of the calls inside
future{}
fail, the long-lived CoroutineScope associated with the cache is canceled, which I don't want. What I want basically is a supervisor scope nested inside the passed-in CoroutineScope, created at cache construction time. But
supervisorScope
doesn't seem to be what I want — I can't call that at cache construction time because I don't want to actually wait before returning like a supervisorScope does! Is there some other API I should be using here? I feel like maybe the answer is
SupervisorJob()
but I am still kinda confused about the distinction between Job and CoroutineScope — I can make a
SupervisorJob(coroutineScope.coroutineContext[Job])
but I'm confused about how to extract a CoroutineScope from it that I can use for launching coroutines.