On 06/10/2011, at 10:16 AM, Etienne Studer (practicalgradle.org) wrote:
>> On 06.10.2011, at 11:04, Luke Daley wrote:
>>
>>> This came up (kinda) on the forum recently: http://gsfn.us/t/2gmv8
>>>
>>> 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?
>>
>> ran into the same issue. I think it would be great if the tasks were
>> configured by the time they are available to a call-back.
>>
>> I believe this also means that when plugins add tasks, they should do that
>> as the last step, i.e. after having configured the task. For example, see
>> MavenPlugin#configureInstall where the task is first added and then
>> configured.
>
> In case my example sounds confusing: MavenPlugin#configureInstall is an
> example of a plugin that would have to be changed to first configure the task
> and to then add the task afterwards.
This would need a new method that we don't currently have, i.e. one that
creates a task without adding it to the container. This is probably not a bad
idea.
Talking more generally about the issue…
There is a little bit of a risk here in that we start to make people more
reliant on order, when we should be promoting “laziness awareness”.
There's a balancing act here that's probably going to be difficult to get
right. Supporting laziness is definitely better in the long run, but it's
another learning curve / barrier. I feel that we shouldn't force lazy wiring on
people, but supporting both styles has the drawback of being potentially
confusing to users.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
