vocabulary: the configuration dilemna

[Xavier Hanin <xa...@gmail.com>]

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:

Re: vocabulary: the configuration dilemna

[Xavier Hanin <xa...@gmail.com>]

On 3/24/07, Gilles Scokart <gs...@gmail.com> 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 <xa...@gmail.com>:
> > 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 <jm...@clearstorysystems.com> 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:xavier.hanin@gmail.com]
> > > Sent: Wednesday, March 14, 2007 12:09 PM
> > > To: ivy-dev@incubator.apache.org
> > > Subject: Re: vocabulary: the configuration dilemna
> > >
> > > On 3/14/07, James Mochel <jm...@clearstorysystems.com> 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:xavier.hanin@gmail.com]
> > > > Sent: Wednesday, March 14, 2007 4:29 AM
> > > > To: ivy-dev@incubator.apache.org
> > > > 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
>

Re: vocabulary: the configuration dilemna

[Gilles Scokart <gs...@gmail.com>]

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.

Gilles


2007/3/17, Xavier Hanin <xa...@gmail.com>:
> 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 <jm...@clearstorysystems.com> 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:xavier.hanin@gmail.com]
> > Sent: Wednesday, March 14, 2007 12:09 PM
> > To: ivy-dev@incubator.apache.org
> > Subject: Re: vocabulary: the configuration dilemna
> >
> > On 3/14/07, James Mochel <jm...@clearstorysystems.com> 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:xavier.hanin@gmail.com]
> > > Sent: Wednesday, March 14, 2007 4:29 AM
> > > To: ivy-dev@incubator.apache.org
> > > 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

Re: vocabulary: the configuration dilemna

[Xavier Hanin <xa...@gmail.com>]

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 <jm...@clearstorysystems.com> 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:xavier.hanin@gmail.com]
> Sent: Wednesday, March 14, 2007 12:09 PM
> To: ivy-dev@incubator.apache.org
> Subject: Re: vocabulary: the configuration dilemna
>
> On 3/14/07, James Mochel <jm...@clearstorysystems.com> 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:xavier.hanin@gmail.com]
> > Sent: Wednesday, March 14, 2007 4:29 AM
> > To: ivy-dev@incubator.apache.org
> > 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
> >
>

RE: vocabulary: the configuration dilemna

[James Mochel <jm...@clearstorysystems.com>]

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:xavier.hanin@gmail.com] 
Sent: Wednesday, March 14, 2007 12:09 PM
To: ivy-dev@incubator.apache.org
Subject: Re: vocabulary: the configuration dilemna

On 3/14/07, James Mochel <jm...@clearstorysystems.com> 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:xavier.hanin@gmail.com]
> Sent: Wednesday, March 14, 2007 4:29 AM
> To: ivy-dev@incubator.apache.org
> 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
>

Re: vocabulary: the configuration dilemna

[Xavier Hanin <xa...@gmail.com>]

On 3/14/07, James Mochel <jm...@clearstorysystems.com> 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:xavier.hanin@gmail.com]
> Sent: Wednesday, March 14, 2007 4:29 AM
> To: ivy-dev@incubator.apache.org
> 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
>

Re: vocabulary: the configuration dilemna

[Xavier Hanin <xa...@gmail.com>]

On 3/14/07, Gilles Scokart <gs...@gmail.com> 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:xavier.hanin@gmail.com]
> > Sent: mercredi 14 mars 2007 9:29
> > To: ivy-dev@incubator.apache.org
> > 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
>
>

RE: vocabulary: the configuration dilemna

[Gilles Scokart <gs...@gmail.com>]

+1, the new version in apache package already break the API.  So why not do
this change also.


Gilles

> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: mercredi 14 mars 2007 9:29
> To: ivy-dev@incubator.apache.org
> 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

RE: vocabulary: the configuration dilemna

[James Mochel <jm...@clearstorysystems.com>]

+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. As long as we documented
and trumpeted that this release contains non-backward compatible change.


Jim

-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com] 
Sent: Wednesday, March 14, 2007 4:29 AM
To: ivy-dev@incubator.apache.org
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

Re: vocabulary: the configuration dilemna

[Xavier Hanin <xa...@gmail.com>]

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