[justoreply]

given a project split in several modules, we don't want to build them separately, we want to type check at compile time that everything works and we have a single build system managed by Gradle. Gradle is smart enough that if we are changing a module, we can build all the dependent ones, and only them.

The cache system comes into play when someone is changing something: when a developer is updating the code locally with changes from other developers, they don't have to compile and run tests of modules they are not changing locally, as gradle is downloading automatically the changes from the build cache.

* Developer 1 changes module A * code is pushed * CI pipeline is running and uploading all the artifacts (final production code, final test code, test results) * Developer 2 pull code locally * gradle find changes from the last local run, it tries to compile/run the tests of updated modules but results are downloaded from the cache, instead of running locally

[eitland]

> Gradle is smart enough that if we are changing a module, we can build all the dependent ones, and only them.

I rarely build big projects, we usually create multiple small ones instead and if necessary reuse through artifactory or something, but unless I misunderstand you, this is exactly the same as Maven does in a multi module project, isn't it?

> The cache system comes into play when someone is changing something: when a developer is updating the code locally with changes from other developers, they don't have to compile and run tests of modules they are not changing locally, as gradle is downloading automatically the changes from the build cache.

But why should other developers have a relation to the source of dependencies except for debugging?

Isn't it better to upload the packaged jars to some kind of artifact repository at the end of their build pipeline?

[justoreply]

> I rarely build big projects, we usually create multiple small ones instead and if necessary reuse through artifactory or something, but unless I misunderstand you, this is exactly the same as Maven does in a multi module project, isn't it?

for example when when you change an api module in a multi module project, gradle will rebuild/test all the modules that depends on that: you can't do automatically with maven, if you have separate artifacts shared via a repository (at least for my understanding). You can use a reactor module, but maven is not caching efficiently in local builds and not caching at all from a common, distributed cache.

> But why should other developers have a relation to the source of dependencies except for debugging?

Because in a multi module project, each developer has access to the complete project source code and can change whatever module: this is the whole idea of the setup (monorepo idea as Google, for example). In this scenario it is possible to have fine grained module boundaries without the cost of creating new project or the evolution of the interface. If a module doesn't provide the information needed it is easy to change it and gradle will rebuild everything that depends on that. If a new module is needed, it is just a new directory with a build.gradle file in it.

Just to be clear, the end result of a multi module project, at least in my setup, is the creation of single artifact that is going to be deployed.

[eitland]

Thanks, I guess I am underestimating the complexities of monorepos.