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/
