Personally, I think we should deprecate ivy:configure (keep it working, but with a warning message).
I think that the data type approach is more intuitive for an ant user than the current procedural approach. So, I'm not worry about the additional complexity. I remind me when I started to learn ivy that the 'hidden side effect' of an ivy:configure was the first obstacle I met. I think the ivy:settings with a visible id will eliminate this obstacle. Now, it is true that the current users will have to learn the new approach, and most probably adapt slightly their script. Anyway, the difference between the two options is minimal in the code. It's just the warning that says that it is deprecated. Note also that the fact that we have a mandatory id into the ivy:settings doesn't means that the attribute settingsRef is mandatory. Gilles > -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: mardi 10 avril 2007 11:03 > To: [email protected] > Subject: Re: Changed default settings > > On 4/10/07, Gilles Scokart <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I did already take a quick look at the previous patch, and I was only > > > > wondering if adding an "id" attribute to ivy:settings wouldn't cause > > > > problems since the "id" attribute has a special meaning in Ant. > > > > > > > > > Mmm, yes, you're right, I remember we had a problem with id on > cachepath > > > task. So I'll use settingsId instead of id, unless someone give me a > > > better > > > option. > > > > > > > Personally I preffer to keep the 'id' as it is the standards in ant for > > reference. > > > I'm not sure of the implications, but as far as I understand 'id' is the > best solution if we define a datatype, but not if it's a task. > > We could make it a datatype (again). Indeed the execute method is now > > finally empty. The only thing it does is to set a default value to the > > id. > > But if we make it mandatory, the execute method becomes useless, and the > > task can be a datatype. > > > > IvyConfigure should however stay a task to allow keeping the id optional. > > > This means that either: > * we would not deprecate configure, and thus have two ways to load > settings > in Ivy: using the settings datatype, or the configure task. > * we deprecate configure, and everybody need to understand somehow the > concept of scoping and what's happening behind settings loading > > I'm not sure what's the best solution. On one hand I don't like having two > very similar solutions for almost the same thing, and on the other hand I > don't know if the scoping concept will be understood easily by users. The > advantage I see to the second solution is that it will somehow force > people > understand some things which may be difficult to debug otherwise. > > WDYT? > > I can have a look on it if you want, but it will take a few days to > > integrate this (and your last changes) into the patch. > > > I think we first need to make sure of what we really want, before doing > any > further modification. This may imply that we won't integrate this in the > first alpha release. But since it's only a first alpha release, I don't > think it's too much a problem. > > WDYT? > > - Xavier > > Gilles > > > > > > > > > > > -- > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/ > Manage your dependencies with Ivy! > http://incubator.apache.org/ivy/
