My gradle sync times (android studio) are getting ...

# gradle

[ursus]

My gradle sync times (android studio) are getting quite annoyingly long, so I wanted to implement lazy tasks (as I have bunch of static analysis, test setup).

First, I naivelly tried to delete those tasks, to see what would be the best case scenario -- and turns out, it did almost nothing

Only thing that seems to improve sync times, is simply to not sync everything

I have a monorepo setup, a single gradle project with 3 application modules (3 apps) and many shared code modules

Most of the time one only works on a single app, so its not necessary to have the other app's modules loaded (and CI will check for breaks everywhere anyway)

Is there something more sophisticated other than commenting out modules from settings.gradle ?

(I noticed the Load/Unload Modules... intellij option, which does exactly that, but for builds (green hammer icon), and sync times stay the same, even with the other apps modules unloaded -- so a no go)

[Vampire]

Maybe you could consider switching from one build with many subprojects to multiple builds that you draw together using a composite build. Then you can open each of the individual builds (and only its dependencies) in the IDE, but not the sibling projects

[ursus]

Not sure if I know what you mean. Do you suggest multiple gradle projects?

[Vampire]

Mutliple projects is what you have, one build with multiple projects

[ursus]

oh yea gradle semantics project = module?

[Vampire]

What I suggest is mutliple builds, each with potentially mutliple projects or not, however you want to structure exactly

[Vampire]

Depends on what namespace you take "module" from

[ursus]

hmm intellij I guess

[Vampire]

In IntelliJ terms it is module, yes

[Vampire]

In Gradle terms or Eclipse terms it would be project

[ursus]

and how does gradle call the most top level structure if project is taken? 😄

[Vampire]

build

[ursus]

k thanks -- so if I were to work on shared project, then how would I build all apps?

[ursus]

currently its 3 gradlew Xapp:assembleDebug (or the green hammer icon)

[Vampire]

As I said, you can combine them using a composite build.
That is a build that includes other builds

[Vampire]

Originally this was for "I use dependency X, but I now want to use a custom-built version because I change something in library X and want to test it with my project"

[Vampire]

A bit like the maven local repository, just that you don't need to build and install X manually after a change, but you just build your project and it will automatically build X if necessary

[Vampire]

But use-cases for composite builds greatly expanded and they can as well be used as structuring element within one repository

[ursus]

okay I never head of that one, guess I only composed projects

is it this one? https://docs.gradle.org/current/userguide/composite_builds.html

[Vampire]

exactly

[ursus]

I see but a naive question, my folder structure looks like this

/app1
/app2
/app3
bunch of shared library modules

how would my project pane look like in intellj? would I see the shared libraries sources?

[ursus]

currently since its a single build I see everything as the top level build file is in the root directory

[Vampire]

My crystal ball is at the repair shop, I have no idea how you plan to structure your build, but I guess you would for example have individual builds for the shared modules and for each app module and the app modules include the shared module builds. And if you want all of them together in one build you maybe have in the root another build that includes the app builds. If you then open the app1 build, you will have its sources and also all sources of the builds you included in it.

[ursus]

yea build per app, sorry, I was wondering if it will be able to navigate app2's code in the IDE; since I presume app2 wont be included in the sync, nor build nor search (when opening app1)

[ursus]

basically as you guess, its means to improve dev ux for a developer that only cares about say app1 and its dependencies

[Vampire]

Exactly

[corneil]

We had a project with 300 modules in a monorepo with CVS. The settings file would check which modules were present and only include them. project dependencies were dynamically changed to maven dependencies if not present. So developers could checkout what they needed and work locally.