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. regardless, your
project has been a life saver for us. thank you.
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
>
>
>
