On 07/10/2011, at 1:24 AM, Peter Niederwieser wrote:
> Adam Murdoch wrote:
>>
>> A main use case for the callbacks is to provide default values before the
>> configuration closure is applied:
>>
>> // in my root build.gradle, or some plugin:
>> tasks.withType(Jar).all { destinationDir = 'someDir' }
>>
>> // in my build script
>> task myJar(type: Jar) {
>> destinationDir = 'some-other-dir'
>> }
>>
>
> The problem is that both scenarios are feasible. The one where the parent
> script provides defaults, and the one where it enforces/overrides values.
> Maybe we could support both? E.g.
>
> tasks.withType(Jar).defaults { ... }
> tasks.withType(Jar).enforce { … }
The problem with this is that we are going to have to make some kind of
DomainObject contract and only those objects can be used with our collections
and I'm not sure we want to tie them together like that. It also seems weird to
force people to do this via the containing collection, i.e. you'll need to be
able to do it on a per task basis.
That said, I guess we could add methods to TaskContainer that knows about these
lifecycle hooks of Task (and other domain objects) and provides shortcut
methods. I'd rather go in the direction of trying to unify these collection
types for consistency though I think.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
