https://kotlinlang.org logo
Join Slack
Powered by
something seemingly trivial: I want to have a mult...
# getting-started
p
something seemingly trivial: I want to have a multiplatform Gradle module (so far with just the 
jvm()
target), and a JVM-only module that depends on the first one, both in the same project. The problem: the consumer doesn't see the functions from the library. Here's a reproducer: https://github.com/krzema12/jar-inspector/tree/kmp-module. What am I missing?
see the commit on the tip of this branch: https://github.com/krzema12/jar-inspector/commit/2794430e2e2de617f630fc2e36af2547a8a9538d - all I'm trying to do is to commonize the 
library
module (JVM -> common). If 
library
is purely JVM, it works
r
Shouldn't you keep the sources in 
jvmMain
or 
commonMain
instead of 
main
directory?
p
thanks 🤦‍♂️
v
More a question for #C19FD9681 🙂 Other than that 
src/main
is not right for KMP
👍 1
Oh, too late 😞
p
ironically, I filed https://youtrack.jetbrains.com/issue/KT-74305/Warn-if-other-non-empty-dirs-on-source-set-level-exist several days ago, myself, and got caught on doing it myself this time!
v
I don't think that would be a good idea.
Other plugins could for example handle directories there. If you for example also apply the 
groovy
plugin, it would handle 
src/main/groovy
, ...
p
that's true, however I still think that it would be nice to catch these kinds of situation. Another idea: Gradle could check which source sets are actually used, and warn about unused ones? Of course Gradle isn't aware of a random piece of code reading the directory through pure Java API, but some kind of declaration-based validation could be used here
v
Well, the error usually should be visible pretty fast by things not being available. Or if you open the project in an IDE, you also will right away see that the directory is not a source root. 🙂 And as mentioned in your ticket by someone else, there could also be files handled completely outside of Gradle but by some other tool, ... 🤷‍♂️
p
Well, the error usually should be visible pretty fast by things not being available.
the motivator for the ticket was releasing a library with nothing inside it
I agree and understood that Kotlin is not the only consumer of 
src
dir, right - that's an important point
v
the motivator for the ticket was releasing a library with nothing inside it
That's maybe more a sign that tests are missing 😄
p
if we had tests in 
test
instead of 
commonTest
they wouldn't be run...
only another consuming module, unchanged, would be able to catch it
v
Well, no matter what validations someone adds, somehow you will always be able to bust them. 😄
So for the tests also being wrong, then you should maybe have coverage recorded and a validation that coverage hits some minimal value 🙂
p
yeah, some coverage tool might catch it, it would have a division by zero 😄
anyway, an interesting problem with not that clear solution, and still requires us to remember about renaming
41 Views
Open in Slack
PreviousNext
Powered by