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
