A few pointers: * You don't have to hardcode things. You can use Gradle's APIs to say things like `foo.dependsOn(tasks.withType(Test))`.
* You can put common build logic into its own file and apply it many times with `apply from:`. * You can put common build logic into a parent build script (e.g. inside `subprojects { ... }`) * Currently, only one settings.gradle per build is supported (i.e. no nesting), but as you already mentioned, you can script this file to dynamically include projects. * An alternative/complement to using multiple projects is to use multiple source sets. You can find more information on these topics in the Gradle user guide (http://gradle.org/docs/current/userguide/userguide_single.html). -- 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/issues-advises-with-deep-multi-project-build-structures-tp5140721p5140923.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