The project 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
Call the webpieces build to generate a local release zip file
Unzip the release can call createTemplateProject.sh generating a project with gradle multi-project build
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?
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 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.