https://kotlinlang.org logo
Join Slack
Powered by
Usual story: I've a multi-platform library which i...
# multiplatform
d
Usual story: I've a multi-platform library which is consumed by both Client and Server parts of my App. I notice when the Server (a JVM-only project) builds, I see in the log 
WARNING: Ignoring dependency of module 'my-common' on module 'my-server'. Java modules cannot depend on Android modules
. Firstly this log message seems the worded the wrong way around (it's 'my-server' depending on 'my-common'), but I'm assuming it appears because the 
common
module uses the Android plugin for the benefit of its Android source set. This seems like a potential problem to me - is there no way to constrain the application of the Android (or other plugins) to only the build of a specific source-set? Otherwise I see this scheme spelling trouble for inter-module dependencies where multi-platform libraries are concerned.
a
Why does your 
common
module need to know anything about Android?
d
Because it's a Multiplatform Library which needs to be common to JVM (Sever), and the two Client targets; Android and iOS.
...one of the other targeted platforms is the JVM and I want to depend on that in a Java Server project.
k
it does seem strange for a common module to have target-specific dependencies
does expect/actual not solve your use case?
d
On the contrary, I don't think there's anything unusual about this use case: I have a Gradle Module which is going to contain Data Model files.
This is the most common and basic thing one would like to share between Server and Client.
If I just wanted to share between Java Server and Android Mobile Client, then sure, there is no need for MPP or the Android plugin, it can just be a plain Kotlin/JVM module.
k
that doesn't indicate why there would need to be a dependency on Android from within the common module
d
But as soon as you introduce iOS, it's necessary to become a MPP Module. I guess I could exclude the Android plugin even then, and just have it JVM & Native.
But this feels like an artificial restriction due to limitation in MPP's design.
@Kris Wong Ok concrete use case then; I have a library I'm creating called `KImage`; which can be used to handle images in a common API. Ideally this will adopt platform specific ways to encode/decode image formats via expect/actual.
It's normal that I would want to utilise such a library on both my Server and Client, to perform image handling/processing on both sides.
But as things stand, I will get a warning when using it from the Java Server project, because an Android target exists in the MPP module.
Actually, it's not much of a practical issue because it does work.
It's just worrying that there's a message in the log explicitly stating that it won't work (even though it does)
k
i think i am misunderstanding. so the android dependency is not in the common module, it's in the android target?
d
I think we need to be clear on the terms Module and Target.
The Android dependency is certainly not in the Common target of the MPP module.
When I say Common Module, I don't mean the platform common Target.
I mean Common between Server and Client.
k
we can say common source set, since it's technically not a module as far as gradle is concerned
d
Agreed; I am using the term Module consistently to the Gradle terminology throughout.
No platform specific dependencies in the common source set of course.
I should avoid using the word 'common' for the module then - it just means 'shared' in the broader sense.
Restating: If you have an MPP module that is shared between Server and Client, and it has an Android source set, you can't use it in a Java project without getting a warning...
...how's that 🙂
k
gotcha
d
My bad, I should have gone with that description from the outset.
k
but in theory you could publish the jar and pull that artifact in the java server project w/o issue?
d
Yes, you could.
But in practice, multi-module projects are often developed simultaneously as a matter of code organisation.
k
understood
d
So it's not that comfortable to have such warnings. As I mentioned, it actually does work, the warning is inaccurate.
But it makes me wonder about the integrity of the MPP model, that plugins are seeing a problem.
k
i actually set my projects up to make it easy to switch between an artifact dependency, and a gradle submodule
👍 1
d
That's why I raised it.
k
because most team members don't need to build the MPP source
but that doesn't really address your concern, I suppose
d
No, but sincerely, thanks for helping me to restate my question more clearly. I may raise an issue in YouTrack based on that.
🍻 2
As the warning itself is, at least, inaccurate.
2 Views
Open in Slack
PreviousNext
Powered by