On 11/10/2011, at 11:17 PM, Etienne Studer wrote: > I might not have understood every detail you've described but one thing I got > out of it is that a cleaner solution seems to be to create a domain object > that describes what the variants produce. The thing that worries me is that > if I write a Gradle script that requires variation in behavior, I might end > up having to write such domain objects, which sounds like a big obstacle if I > just want to get my build working (no reusage or generalization required). > Hence, an approach like Hans' sounds appealing to me since I can easily grasp > and implement it as a script writer. > > Or maybe I just did not understand your explanation well enough and your > solution is very easy and intuitive to appy for script writers.
In this case (testing), Gradle would be providing the domain objects and the wiring would be manageable for a script writer that knew how to “connect dots” so to speak. So, in most case there's just a little more API to learn. When you start to get into more custom scenarios you may have to start doing some modelling yourself though. The next books in the O'Reilly Gradle series will start to go down this road. Personally, my opinion is that this ability to model without having to go through *any* ceremony is Gradle's ultimate strength that enables all the other cool things. As time goes by I'm confident that this will become more “accessible” through documentation and better API. My point being that we should play to that strength and then work to make it nice/easy for users to do the same. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
