And is we want we could still add :
> <ivy:anytask ....>
> <ivy:settings file="..."/>
> </ivy:anytask>
> As an alternative to
> <ivy:configure settingsId='...'/>
> <ivy:anytask settingsRef='...'>
> </ivy:anytask>
>
> I know that would make two ways to do the same thing but that kind of
> alternative is ususal in ant.
You use ivy:settings and not ivy:configure in the first case, is it
intentional? Anyway, I agree that this kind of alternative is not unusual in
Ant, and I like the implicit scoping it provides. Now will it be easy to
provide this implicit scoping using a task container? I don't know how it
works, but the task container will have to set the settingsId in the nested
configure task before executing it. I guess this is possible, but we should
check before if it's what we want.
Yes it was intentional. With that structure ivy:configure is a task,
while ivy:settings is a datatype that can be placed as a child of any
ivy task as an alternative to the settingsRef attribute.
So that we don't need any "dirty" hack using Task Containers.
Anyway, I would really apreciate some advice from ant people about the
'imperative' style of <ivy:configure>, compared to a more
'declarative' style of <ivy:settings> . The imperative style is
unusual in ant, mostly when working with id. But there is
counter-example. For instance <property> task is a task that has side
effect for the next executed tasks.
--
Gilles SCOKART
