On 06/10/2011, at 2:04 AM, Luke Daley wrote:
> This came up (kinda) on the forum recently: http://gsfn.us/t/2gmv8
Maybe. I think a much better solution to that problem is to use a
DomainObjectCollection of Container objects, and have the deploy and install
tasks refer to that. Trying to use callbacks to do try to wire task properties
together is complicated with with 2 tasks (install and deploy). It will get
even worse if you try to add a stop or start or undeploy task with that
approach.
>
> The proposition is that when adding a task with a configuration closure, the
> configuration should be applied before the task is added to the container.
> This would mean that any callbacks registered on the container would get the
> configured task. I can see that this would be a good thing and would be
> trivial to make happen.
>
> Can anyone think of a reason not to do this?
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'
}
configurations.all { transitive = true }
configurations {
custom { transitive = false }
}
If we were to change the behaviour of the callbacks, we'd need some way to
inject these default values.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
