# How to call multiple separate multi-project gradle builds?
**URL:** https://discuss.gradle.org/t/how-to-call-multiple-separate-multi-project-gradle-builds/35524
**Category:** Help/Discuss
**Created:** [April 2, 2020, 1:30pm UTC](https://discuss.gradle.org/t/how-to-call-multiple-separate-multi-project-gradle-builds/35524 "2020-04-02T13:30:41Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@deanhiller](https://discuss.gradle.org/u/deanhiller)
#### Post date: [April 2, 2020, 1:30pm UTC](https://discuss.gradle.org/t/how-to-call-multiple-separate-multi-project-gradle-builds/35524/1 "2020-04-02T13:30:41Z")
The project [https://github.com/deanhiller/webpieces](https://github.com/deanhiller/webpieces) is a webserver as a library BUT it generates your first Server.java with some other example code to get you started AND along with that generates a multi-project build for the person using webpieces to get started.
Currently, I use a \*.sh script to
1. Call the webpieces build to generate a local release zip file
2. Unzip the release can call createTemplateProject.sh generating a project with gradle multi-project build
3. Call the templates gradle build
Ideally, I would like to convert the \*.sh into a gradle build, but of course step 3 does not even exist until 1 and 2 are done.
LASTLY, we have been spinning up microservices with webpieces like a beast and have around 5 now but hacked a real UGLY fix of linking dirs as a temporary work around to share code(which should be a library jar of course). We want to fix this ASAP. Each of the 5 projects are a multi-project build from webpieces. Cleary, we want to move library code out which will result in about 3-4 more projects. Do we have to essentially pull all our subproject {} and allprojects {} sections into one master build.gradle file at the top level OR is there a way to call each multi-project build? Realize if we call each multi-project build, we need some way of calling the new library projects and delivering those so the other projects can compile as well.
As a side note, I think this would definitely not scale to the size of a mono-repo like twitters if there is one build.gradle file and 1000 projects, or would it?
Perhaps I should have posted 2 questions but these were extremely related but could be different answers. I am wondering on the 2nd one if we just go to ONE master gradle file for all projects?
thanks,
Dean
---
### Author:  [@ljacomet](https://discuss.gradle.org/u/ljacomet)
#### Post date: [April 3, 2020, 4:12pm UTC](https://discuss.gradle.org/t/how-to-call-multiple-separate-multi-project-gradle-builds/35524/2 "2020-04-03T16:12:01Z")
Hello,
For the first point, Gradle does not really support dynamically adding projects into a running build. So you cannot really generate a project and then consume it as if it was part of the outer project.
However you could orchestrate the project creation with a Gradle build, but step 3 would be equivalent to running an external command, even if it happens to be a Gradle invocation.
For the second part, the usual recommendation is to group together things that have the same release lifecycle. If your set of projects fall into that category, then grouping them as subprojects in a global project could be an answer.
If the release cycles are different, you could look into [composite builds](https://docs.gradle.org/6.3/userguide/composite_builds.html) as a solution or potentially use a shared project that you publish and consume as a binary dependency most of the time but have a way of using as an included build when refactoring it for a special case.
---
### Author:  [@deanhiller](https://discuss.gradle.org/u/deanhiller)
#### Post date: [April 3, 2020, 5:42pm UTC](https://discuss.gradle.org/t/how-to-call-multiple-separate-multi-project-gradle-builds/35524/3 "2020-04-03T17:42:00Z")
@ljacomet, thanks!!! I read up on composite builds and had a few more questions(but the concept rocks!!!)
I just posted two new questions on composite builds…
> [@Gradle composite builds and setup for breaking changes?](https://discuss.gradle.org/t/gradle-composite-builds-and-setup-for-breaking-changes/35538):
>
> We have an automated build system that does the following that we documented here Now, for a mono-repo, it’s very important to not build the world and only build what needs to be tested from the changes. (This is done at twitter so they can confirm they are not breaking master for any other teams). sooooooo, I am wondering how to tie this into Composite builds Git changed files in a way that if I change files in library A, then library A build is run, AND then project C and D are run wit…
and
> [@Gradle Composite builds and 3rd party jars (how to prevent jar hell sort of...?))](https://discuss.gradle.org/t/gradle-composite-builds-and-3rd-party-jars-how-to-prevent-jar-hell-sort-of/35537):
>
> At twitter, the whole repo uses the same version of each jar(pretty much). there is a master list. I have this master list in a multi-project build which works great BUT looking at composite builds here There seems to be no example how I can bring my HashMap up one level to the composite build such that every build gets this map of jars to reference if they depend on anything in it or not. Is there a way to even do this or am I screwed here (allowing jar hell to creep in much more easily).…