I often wondered why the class/property is named Gradle and not Build. Now it makes sense.
I like approach #1. It seems useful to model both an invocation of Gradle and a build, and this is the cleanest way to do so. I wonder if it makes sense to spin this further and model a scope that's bigger than a single invocation. For example Gradle -> Invocation -> Build. <dream-mode> It would be nice if one invocation of Gradle was called 'build', and 'project' would be more aligned with 'software project'. (I'm constantly fighting with Gradle's use of the word 'project' - a (software) project has a multi-project build. Huh?!) My favorite language would be Gradle -> Build -> Project -> Module. I envision that a build's projects would be processed in strict order, but a project's modules not (i.e. tasks from different modules could be interleaved). </dream-mode> -- 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/The-Gradle-interface-and-init-scripts-tp5012263p5023223.html Sent from the gradle-dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
