We have the following situation. Our gradle’s submodules can be divided in the following groups:
- server’s: frequently changed submodules
- javafx_client’s: frequently changed submodules
- shared’s: contracts between javafx and core_systems, changed, but not so frequently as the server’s or javafx’s
- libraries - relatively small, stable packages imported in javafx and server submodules.
The problem is: our root project has now about 60 submodules. We are using IntelliJ Idea, so every time someone changes something in any build.gradle file, he or she has to refresh all Gradle projects in IntelliJ. In our case it takes about 10 minutes to finish.
Also, gradle configuration phase takes a while (+/-90s), so every time we want to build something we have to wait first. In our case it is rather often. --configure-on-demand helps a little bit, but still it takes 45s to configure the server side (without compile and deploy)
To solve this, I suppose, we have to minimize the number of the submodules of our core build.
At the moment we don’t have Nexus or any other artifacts repository - just to keep it as simple as it is. All the dependencies between our submodules looks like: compile project(:some:path). And every time someone want to update a library, just pushes changes to git, and everyone has the most updated version.
So, my question is: how to speed up the builds and keep it simple? Should we pre-built the libraries and install it in local repositories? How then the developer will know if someone changed something in them after the git’s pull?
Thanks for any idea, suggestion.