What would be the best reasons to use Gradle subprojects instead of tossing everything into one big ...

# gradle

[Karlo Lozovina]

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...

[Rob Elliot]

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.

[Rob Elliot]

(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.)

[christophsturm]

if you have subprojects that don’t depend on each other gradle can build them in parallel to speed up the build

[Karlo Lozovina]

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...

[Karlo Lozovina]

parallel builds also sound useful, thanks!

[Rob Elliot]

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.

[christophsturm]

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

[Tomasz Krakowiak]

For me the only valid reason is source organization : )

[Karlo Lozovina]

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! :)