On 4/10/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
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.
Your opinion is very valuable, because obviously I can't say anything like this, and it's difficult to draw conclusions from what I've heard so far on the forum/mailing lists: people having troubles sometimes complain, but people understanding quickly seldom say so. Now, it is true that the current users will have to learn the new approach,
and most probably adapt slightly their script.
I don't think this will be a real problem: current users will still be able to use the old approach until we actually remove configure (and we won't do that any time soon), so they will have time to adapt. And it's not that difficult to understand I think. If we explain correctly that now settings is a datatype as a fileset is, and that the resolve task need such data to proceed as a copy need a fileset to proceed, then I think people will understand. And to actually make it work like that, I think we should make it possible at least for the resolve task to specify the settings to use as a nested element instead of a reference. Anyway, the difference between the two options is minimal in the code.
It's just the warning that says that it is deprecated.
You're right, it shouldn't be too much a big deal. Note also that the fact that we have a mandatory id into the ivy:settings
doesn't means that the attribute settingsRef is mandatory.
Yes, but in this case I think it's more confusing if you specify the id in ivy:settings and not in the resolve task, for instance. If we really want to go on the explicit way, I'd prefer to be consistent and make the settings mandatory in tasks requiring settings (like resolve). I see two ways to give the settings to such tasks: settingsRef or nested settings. Thus I would deprecate the use of resolve without one of those two options (i.e. display a WARNING). - Xavier 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/
-- Learn Ivy at ApacheCon: http://www.eu.apachecon.com/ Manage your dependencies with Ivy! http://incubator.apache.org/ivy/
