On 3/14/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
+1, the new version in apache package already break the API. So why not do this change also.
And this wouldn't break backward compatibility, you would only have some deprecation warnings. - Xavier Gilles
> -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: mercredi 14 mars 2007 9:29 > To: [email protected] > Subject: Re: vocabulary: the configuration dilemna > > Oops, mail was sent too early! Here it is again: > > Hi, > > > > From almost its beginning Ivy suffers from the two meanings of the > > "configuration" word. This has already been discussed, and maybe the > > migration to Apache is a good time to review this issue. In the source > code, > > most of the time what wasa previously known as configuration file is now > > called settings. > > > > So I would like to know if you think we could go even further in this > > direction, and replace the official naming by settings. Here is my > > proposition: > > - the configure task would remain configure, because I don't see how to > > rename it. But if somebody has a better idea, we could provide a renamed > one > > and deprecate the old one. > > - the usual name for the settings file would be ivysettings.xmlinstead > of > > ivyconf.xml. When no settings file is given, Ivy would automatically > > configure itself with the following process: > > * check the existence of a file at the following locations > * [working dir]/ivysettings.xml > * [working dir]/ivyconf.xml (same as today, for backward compatibility, > but warn as deprecated) > * [ivy home dir]/ivysettings.xml > * use "in jar" default settings as today > > - The root element of the settings file would be ivysettings instead of > ivyconf (ivyconf being still accepted but deprecated) > - the documentation and tutorials would reflect the change > > What do you think? > > - Xavier
