Hey my library has a `implementation project("…")`...
# gradle
a
Hey my library has a
implementation project("…")
dependency on a base module but when I generate the jar it doesn’t include the base module classes, any ideia why?
v
Because that's normal. You declare a dependency on that project. You should normally not package classes from multiple project into one, but just publish each of the jars and their dependencies.
a
I want an “internal dependency” before publishing basically
should I just add it to the sourceSets?
instead of a dependency?
v
Hard to give a good avice as it highly depends on the case. Usually if you split things up in projects it has a sense and you should publish it also like that. If you want to combine those in a jar, you need special setup that highly depends on the details. Maybe the
shadow
plugin can help you if you can declare to only include your own classes from the projects in the same build, I'm not sure. I don't like and thus not use it as I have strong feelings against fat jars.
What reason do you have to not simply publish all those jars which is the idiomatic way?
a
because its a simple commons that is used in two other libraries that those are published
no need to publish it
v
Well, if you now have the commons C and the libs A and B that both depend on C. If a downstream project consumes A and B at the same time, they will get the classes of C twice on the class path and maybe in different version which can cause great problems. And latest when someone uses JPMS there will be a big problem as it disallows split packages.
You should really just publish all three and have a proper dependency declared.
It's the easiest, cleanest, and least fragile
a
Ya but the thing is libs A and B are not supposed to be included in the same project u either choose A or B
v
Well, then it might be "ok", but my recommendation would still be to not do it. 🙂
a
Ya but the only way to go is with the source sets right?
basically saying that the Libs include both source sets
v
No, you can also repack the jars contents in the other jar. Like for example having a separate non-transitive configuration to declare the dependency on additionally and then repack its contents in the jar or similar. But as I said, this is highly specific to the case, hard to give a general advice.