ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject Re: Ivy settings management from Ant (was Re: can i call ivy:configure multiple times with different configuration files(which in turn refers different ivy.xmls)?)
Date Wed, 27 Jun 2007 09:56:27 GMT
> 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

Mime
View raw message