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). 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? 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/
