I have several subprojects in a multi-project build, many of which rely on other projects as compile dependencies. Right now I have a solution that works, but I’m afraid that it’s unnecessarily verbose. My root settings.gradle gathers the jobs initially specified by the user, then applies the settings.gradle from each of them if it exists. Here’s an example of on of my subprojects’ settings.gradle:
include ‘:shared:alpha-shared’
include ‘:shared:beta-shared’
include ‘:shared:gamma-shared’
apply from: ‘…/…/shared/alpha-shared/settings.gradle’
apply from: ‘…/…/shared/beta-shared/settings.gradle’
The “gamma” project in this case does not have a settings.gradle of its own because it does not have any project dependencies.
For this same project, my build.gradle looks like this:
dependencies {
compile(
project(":shared:alpha-shared"),
project(":shared:beta-shared"),
project(":shared:gamma-shared")
)
providedCompile group: ‘jstl’, name: ‘jstl’, version: ‘1.2’
}
I’d really like for things to be more dynamic than this. Ideally, Gradle would include the compile dependency projects and apply their settings as if they were transitive dependencies, however this runs backwards to the order in which settings.gradle and build.gradle are evaluated. I thought about using a properties file to hold the names of the projects, but this wouldn’t really solve much–I could do something like “include prop1”, “include prop2”, etc, but the number of dependencies would still need to be hard coded, as would the decision on whether or not to attempt to apply a settings file.
Edit: I guess I should mention that I did originally have a solution in the root project’s settings.gradle in which I programatically loaded a gradle.properties from each included project, then ran a recursive function that included each project listed inside those properties, loaded those projects’ properties, etc. It worked, but it was ugly and I was hoping there was some sort of elegant Gradle way to do this.