The simplest solution is to keep the builds at the same granularity as the source code repositories. That is, you have one build per repository, which also means one settings.gradle. You use project dependencies to reference projects within the same build, and module dependencies (in Gradle's terms) to reference projects in other builds. For the latter to work, at least the "common" builds need to publish their artifacts to an artifact repository (I recommend Artifactory).
In the future, we plan to provide explicit support for builds spanning multiple source code repositories. Other options are to hook builds together via your CI server or to use something like Git submodules to create the illusion of an uber-repository (but think twice before going there). How many build.gradle scripts you have per build is entirely up to you. You could stuff everything into one script at the outer level, or you could have additional scripts for (some or all) projects. Both are common choices. Personally I tend to favor the latter because I don't want to end up with too big a build script. -- Peter Niederwieser Principal Engineer, Gradleware http://gradleware.com Creator, Spock Framework http://spockframework.org Twitter: @pniederw -- View this message in context: http://gradle.1045684.n5.nabble.com/How-to-set-up-multi-product-builds-tp4716825p4717284.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
