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 - 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. - When no <settings> and no <configure> are used and a task doesn't set the settingRef, a default settings will be created. 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/
