j

    Jilles van Gurp

    2 years ago
    I generally advice agains multi module. All you get is slower builds and more lines of gradle code to maintain. Keep it simple. For the same reason, the fewer obscure plugins you depend on the less headaches you have when the time comes stuff needs to be upgraded. YAGNI. If you need separate layers in your architecture, packages are good enough. Typically none of the gradle modules used for anything else than the single app they are a part off and people just tend to copy paste the mess around instead of solving it; so you are multiplying your problems as well.
    genovich

    genovich

    2 years ago
    It makes sense
    But when you enable Gradle buildCache and Gradle remote buildCache you avoid recompilation of modules that don’t changed.
    Even at a local machine
    j

    Jilles van Gurp

    2 years ago
    Incremental compilation inside modules works just as well. Technically, the compiler treats each .class file as a module. I've never been unlucky enough to be on a project necessitating a remote build cache. I work hard to avoid getting bogged down in build times that long. Having a lot of caches just increases the potential for cache coherence bugs. That's why intellij and android studio have a top level menu item labeled "invalidate caches/restart".
    genovich

    genovich

    2 years ago
    Can You suggest something for project which compiles about 40 minutes? I need something to decrease compile time at CI server.
    j

    Jilles van Gurp

    2 years ago
    Yikes, that's long. In that case latest gradle & kotlin should help and more cpu on your CI server.
    also caching dependencies on your ci server helps.
    beyond that, profile the build and see where it spends time.
    genovich

    genovich

    2 years ago
    Thanks, I will check it