ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Blattman <jeffrey.blatt...@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 Mon, 25 Jun 2007 16:12:57 GMT
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.

Gilles Scokart wrote:
>   
>> -----Original Message-----
>> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
>> Sent: lundi 25 juin 2007 16:47
>> To: ivy-user@incubator.apache.org
>> 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 <gscokart@gmail.com> 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
>
>
>   

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message