https://kotlinlang.org logo
#gradle
Title
# gradle
m

Matt Nelson

03/05/2023, 9:06 AM
Have a kotlin multiplatform library I want to publish, but would like consumers to express capabilities when consuming so that they don't get a shit ton of unnecessary transitive dependencies. Something like Rust's
features
expression where consumers opt-in to a feature and the build system handles it. Anyone know how I might best achieve this?
m

mbonnin

03/05/2023, 1:10 PM
Sounds like you need variants?
Kotlin is different than rust though because it is published as binary, not source
Curious how you would handle the different features. Through reflection/ServiceLoader like patterns?
m

Matt Nelson

03/05/2023, 1:19 PM
Kotlin is different than rust though because it is published as binary, not source
Yeah that seems to be the rub. I think a modularized approach that publishes a BOM will probably suffice b/c even with variants, it will still produce
x
amount of artifacts, so.
/cry
m

mbonnin

03/05/2023, 1:24 PM
Sounds like you need to model a "feature" API, a bit like Ktor and engines:
Copy code
val myApi = buildApi {
  installFeature1()
  installFeature2()
  ...
}
Your "core" needs to know about all features
m

Matt Nelson

03/05/2023, 1:38 PM
It's a crypto lib (currently only hashing algos and MACs).
Not sure if that model would work since a user should just be able to call
Sha256().digest(bytes)
v

Vampire

03/05/2023, 3:32 PM
@mbonnin was almost right, the variant link he posted just was a bit too low level. What you want is exactly declaring feature variants. Selecting those even matches your terminology, is done using capabilities. You can have multiple artifacts that are selected by the capability you choose. But as it sounded like you don't want that, you can as well have the same code jar for all the feature variants and just have different sets of dependencies. Practically the proper way to do things, Maven "optional" dependencies were used for. Read more at https://docs.gradle.org/current/userguide/feature_variants.html
7 Views