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? - 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? - When no <settings> and no <configure> are used and a task doesn't set the
settingRef, a default settings will be created.
Sounds fine. Xavier Gilles
> -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: lundi 25 juin 2007 14:50 > 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: > > > > > > > > > > OK, I understand. Could we list the pros and cons of each solution and > > see > > > what's the best solution. The pros I see for a datatype is that we > could > > > use > > > it directly in tasks requiring a settings. For instance: > > > <ivy:resolve file="ivy.xml"> > > > <ivy:settings url="http://myserver/ivysettings.xml"/> > > > </ivy:resolve> > > > > > > I like this option. For people comfortable with ant datatypes, it > should > > > be > > > clear. > > > The cons is that it's counter intuitive for Ivy 1.x users, and not > > obvious > > > for others. It makes the scoping mandatory. > > > > The scoping is not really mandatory. It is only mandatory in the > > declaration of the settings. The other task can still reference > > 'ivy.instance' by default. > > > Yes, but I feel like this is awkward from a user point of view: there is a > default value for the id everywhere but in the settings declaration. I'd > prefer a default everywhere or nowhere. > > I'm just thinking to an other approach. I'm not sure it is clean or even > > will work, but it might be a possible workaround. > > > > We could overwrite the setProject and write a setId method. When > > setProject > > is called first (I think it is normally the case), we could register the > > instance with the id 'ivy.instance' (of this reference is not yet used). > > Then, in the setId, we remove the previously registered reference. > > > > With this hack, you could make the id optional on ivy:settings, but I > > don't > > think it's a good idea because it will not be intuitive that's a > datatype. > > > > I would rather make the settings of the id really mandatory in > > settings. If > > we use the same hack (overwrite setProject and setId), we could register > a > > unusable settings behind 'ivy.instance' when there is no id that report > an > > error when used. > > > > WDYT? > > > Why not, but this means that we make the settings initialization > mandatory, > which was not the case in 1.x. I like the idea of having good defaults to > make the first use of Ivy as easy as possible. What I don't like with the > new approach is that you need to specify an id in settings, not in post > settings tasks, and that there is no error when you don't specify an id. > But > I see no way to raise an error without id, because using settings without > id > is allowed in a post settings task (like resolve). > > So I would really appreciate feedback from users on this subject. My > preference for the moment still goes to undeprecating the configure task. > > Xavier > > Gilles > > > > > > > -- > Xavier Hanin - Independent Java Consultant > Manage your dependencies with Ivy! > http://incubator.apache.org/ivy/
-- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/
