What would be the best reasons to use Gradle subpr...
# gradle
k
What would be the best reasons to use Gradle subprojects instead of tossing everything into one big pile? I have a smallish project of 15-20k lines of Kotlin, and a colleague has been telling me to split it up into multiple subprojects. Doing it naively creates a lot of circular dependencies so I'd have to refactor it a lot...
r
For me the refactor is precisely the reason. Kotlin / the JVM don’t provide a way to enforce dependency behaviours between packages; there’s no (trivial) way to tell the compiler (& IDE) that elements in package
ui
should not depend on public elements in package
db
(or worse, the other way around!). Nor to prevent circular dependencies between packages. By making them Gradle subprojects you can use Gradle’s dependency mechanism to constrain yourself to non-circular dependencies, and if you have to add
implementation(project.ui)
to `db`’s
build.gradle.kts
to make it compile that’s a really obvious sign that something needs fixing.
(There are other ways to do this, of course - I’ve written gradle tasks that use
jdepend
to introspect the dependencies between packages and fail the build if there are illegal dependencies, using a custom dependency declaration file. But the IDE knew nothing of it, so the feedback was painfully late.)
c
if you have subprojects that don’t depend on each other gradle can build them in parallel to speed up the build
k
yeah, although a bit boring and not immediately useful, I see that refactoring the codebase to prevent circular dependencies and clearer separation of concerns would be a benefit in the long run...
parallel builds also sound useful, thanks!
r
I don’t know if JPMS modules can provide the same benefits in one git project? Possibly… don’t know about the parallel compilation, though in principle
kotlinc
should be able to use the module graph to work out which modules can be compiled in parallel… Don’t even know how trivial it is to have multiple modules in the same git project. I’m still a bit green on them.
c
if you have multi module gradle build, idea will import it as multiple modules, and I think it will also build it in parallel, if you enable parallel builds in the build settings
t
For me the only valid reason is source organization : )
k
So, about a week later, few sleepless nights and getting to know Gradle plugins and Java modules much intimately than I ever wanted to: 25% faster builds, resolved lots of sharped edges in internal APIs, lot cleaner and less coupled code now in a few places that were quite hairy... Probably worth it, will modularize again! :)