2007/6/25, Xavier Hanin <[EMAIL PROTECTED]>:
> On 6/25/07, Jeffrey Blattman <[EMAIL PROTECTED]> wrote:
> >
> > see inline ...
> >
> > Xavier Hanin wrote:
> > > On 6/25/07, Jeffrey Blattman <[EMAIL PROTECTED]> wrote:
> > >>
> > >> sorry if i'm lost a little, but this is what i'd expect as a user
...
> > >>
> > >> <ivy:settings/> assumes a default id of "ivy.instance" (or
whatever),
> > >> and any other task that takes a settingsId assumes a default of
> > >> "ivy.instance" if it's not specified.
> > >>
> > >> and of course, <ivy:settings id="X" file="..."/> is valid, and
any
> > other
> > >> task that takes a settingsId attr , and uses "X" will use the
settings
> > >> defined by the associated ivy:settings.
> > >>
> > >> this is what is intuitive from a user's perspective, so it'd be
good if
> > >> there'd by a way to make the code work like this.
> > >
> > >
> > > Thanks for your feedback Jeffrey.
> > > I agree with your feeling, the problem is that the only way to do
what
> > > you
> > > want is to define ivy:settings as a task. And if it's a task, you
> > > can't use
> > > it with the following syntax:
> > > <ivy:resolve>
> > > <ivy:settings file="">
> > > </ivy:resolve>
> > > which has the advantage of making scoping obvious (with no need
for
an
> > > id).
> > >
> > that is interesting, but i would have never thought to try that. for
me,
> > it is more intuitive to do it w/ references ...
> >
> > <ivy:settings id="x" file="..."/>
> > <ivy:resolve settingsId="x"/>
> > > So my proposition is to keep the configure task (which would
behave
> > > exactly
> > > as you expect from the settings), and use settings only with an id
or
> > > within
> > > a post settings task (as you would do with a fileset or any other
ant
> > > datatypes).
> > >
> > > Does it make sense?
> > i hope i am not insulting insulting anyone, but i get the feeling
that
> > might be over engineering to some degree. for users, it may be more
> > important, for a particular task, to have one obvious way to achieve
it
> > as opposed to having multiple ways. then the user has to research
which
> > is better and why they should use one over the other.
> >
> > for example, is:
> >
> > /<ivy:resolve>
> > <ivy:settings file="">
> > </ivy:resolve>
> > /
> > solving a use case that can't be achieved via:
> >
> > /<ivy:settings id="x" file="..."/>
> > <ivy:resolve settingsId="x"/>
> > /
> > or is it just giving the user another way to do the same thing? if i
was
> > a new user, i'd look at the ivy:settings and ivy:configure, and have
to
> > do some reading to understand the difference between them.
> >
> > just my $0.02 ... hope this feedback is of some help.
>
>
> Yes it is. Feedback from users is the best way to achieve a good
product!
>
> I understand your point of view, maybe we should consider only one way
and
> forget about embedding the settings (and thus use a task instead of a
> datatype). I think the original idea behind the datatype was
brought by
> people very comfortable with ant who didn't catch at first time the
relation
> between the Ivy tasks. There is no other ant task which are
dependent on
one
> another like that, using datatypes is more usual.
>
> I won't fight for the datatype, even if I find the solution
elegant, I'm
> used to the way the task work, and using an id for scoping is fine for
me.
>
> Maybe we should start another thread to get more user feedback?
>
>
> regardless, your
> > project has been a life saver for us. thank you.
>
>
> Thanks a lot, it's the best reward we can get from the time we
invest in
the
> project!
>
> Xavier
>
>
> >
> > > Xavier
> > >
> > > Gilles Scokart wrote:
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: Xavier Hanin [mailto:[EMAIL PROTECTED]
> > >> >> Sent: lundi 25 juin 2007 16:47
> > >> >> To: [EMAIL PROTECTED]
> > >> >> 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)?)
> > >> >>
> > >> >> On 6/25/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> > >> >>
> > >> >>> I think I was not clear in my explanations, sorry.
> > >> >>> What I would like to have is :
> > >> >>>
> > >> >>> - When deprecated <configure> is used, no scoping is
> > >> >>> available. settingsRef
> > >> >>> in task doesn't make sense
> > >> >>>
> > >> >> Does it mean that if you use settingsRef in a task it will
raise
an
> > >> error?
> > >> >> Even if you use settingsRef="ivy.instance"? I thought the call
to
> > >> >> configure
> > >> >> with no id was equivalent to <ivy:settings
id="ivy.instance"/>.
Is
> > it
> > >> >> right?
> > >> >>
> > >> >
> > >> > Currently on the trunk, yes, you are right. I just said
that it
> > >> didn't
> > >> make
> > >> > sense, so for me it could raise an error or we could keep the
current
> > >> > behaviour. I'm too tired today to say which approach I would
prefer.
> > >> >
> > >> >
> > >> >> - When a <settings> is defined, id='...' is mandatory. And an
error
> > >> (with
> > >> >> a
> > >> >>
> > >> >>> clear message) is triggered when a task try to use the
settings
> > >> >>> 'ivy.instance' (implicitely or or not) and this instance was
> > created
> > >> >>>
> > >> >> with
> > >> >>
> > >> >>> a
> > >> >>> <settings> without id.
> > >> >>>
> > >> >> Sorry, I'm not sure to fully understand this point. Do you
mean
> > that:
> > >> >> <ivy:settings />
> > >> >> <ivy:resolve settingsRef="ivy.instance" />
> > >> >> will raise a clear error, saying that the id is mandatory in
> > >> settings?
> > >> >>
> > >> >> In this case, what happen if you do this:
> > >> >> <ivy:configure file="ivyconf.xml"/>
> > >> >> <ivy:resolve />
> > >> >> <ivy:settings file="ivysettings.xml" />
> > >> >> <ivy:resolve settingsRef="ivy.instance" />
> > >> >> ?
> > >> >> The first resolve should run ok with the settings loaded from
> > >> ivyconf.xml.
> > >> >> Then will the second resolve use the first settings loaded
with
> > >> configure,
> > >> >> the second one, or raise an error? My guess is that it will
use
the
> > >> first
> > >> >> settings. Am I right?
> > >> >>
> > >> >>
> > >> >
> > >> > Currently on the trunk, again you are right. But I'm not
sure it
is
> > >> > intuitive. I would prefer the second resolve call trigger an
error
> > >> saying
> > >> > that the ivy:settings must have an id.
> > >> >
> > >> >
> > >> >
> > >> > Gilles
> > >> >
> > >> >
> > >> >
> > >>
> > >
> > >
> > >
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> Manage your dependencies with Ivy!
> http://incubator.apache.org/ivy/
>
--
Gilles SCOKART
