On 3/24/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
He, I just think this morning to a name to replace the ivy:configure. If instead of seeing it as a task, you see it as a datatype, it could be named : ivy:setting , ivy:settings, or ivy:engine This was actually the solution proposed https://issues.apache.org/jira/browse/IVY-366 (Scope and status leakage during build lifecycle) I know Maarten is working on it, and has already done a good work to scope the resolution. If Maarten didn't worked yet on the scoping of the configuration (oups, of the settings), I will have a look to see if I can propose a patch.
This sounds like a pretty good idea. I like your idea proposed in IVY-366, and I like this idea of considering the configure task as a data type, and call it ivy:settings. Then we remove any possible confusion. So it's +1 for me. Anybody else has an opinion about that? - Xavier Gilles
2007/3/17, Xavier Hanin <[EMAIL PROTECTED]>: > Since my proposition seems to be accepted, I've created a JIRA issue: > https://issues.apache.org/jira/browse/IVY-438 > > - Xavier > > On 3/14/07, James Mochel <[EMAIL PROTECTED]> wrote: > > > > > > It may not be an issue. Even though we USE ivy:configure and we HAVE > > configurations there doesn't seem to be much confusion (For me or my > > coworkers ) between them. > > > > On the other hand, understanding what configurations in a file actually > > do and how they inherit from each other is something that takes awhile > > to do! > > > > Much of that is the clarity of the documentation. > > > > > > Jim > > -----Original Message----- > > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 14, 2007 12:09 PM > > To: [email protected] > > Subject: Re: vocabulary: the configuration dilemna > > > > On 3/14/07, James Mochel <[EMAIL PROTECTED]> wrote: > > > > > > +1, I for one don't think that most people would be all that upset > > even > > > if the name of the configure task was changed. > > > > > > Changing the name is not the problem, if we still provide the old one as > > deprecated, it shouldn't be too much an issue. It's simply that I don't > > see > > how we could rename it, but I lack english vocabulary, so if someone > > else > > has an idea... > > > > - Xavier > > > > As long as we documented > > > and trumpeted that this release contains non-backward compatible > > change. > > > > > > > > > Jim > > > > > > -----Original Message----- > > > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, March 14, 2007 4:29 AM > > > 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.xml > > > instead 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 > > > > > > -- Gilles SCOKART
