Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)

[Xavier Hanin]

On Fri, Mar 28, 2008 at 4:08 PM, Dominique Devienne <ddevienne@...>
wrote:

> On Fri, Mar 28, 2008 at 8:00 AM, Xavier Hanin <xavier.hanin@...>
> wrote:
> > On Fri, Mar 28, 2008 at 1:23 PM, Gilles Scokart <gscokart@...>
> wrote:
> >  > +1 for me as well (let's put a little bit more presure from the Ivy
> guys ;-).
> >  >
> >  > To come back to the impact on Ivy, I think we should put a note in
> our
> >  > doc saying that using the settings task with an id requires 1.7.1.
> >
> >  We can put a reference to the bug, the problem occurs only when you
> call ant
> >  with multiple targets, each depending on the same settings, so I think
> >  people can use Ivy settings with with ant 1.7.0 without running into
> the
> >  problem.
>
> For the record, I think it's bad Ant style to use ids in tasks. This
> is kept around for BC, but should be discouraged. Using ids on types
> OTOH is OK, and essential to types in fact. If a task should refer to
> part of another task's internal config, this hints to the config
> needing to be its own type referred to by both tasks. It's even OK for
> the type to be implicitly created by the first task, when it receives
> for example a configid="foo" attribute, so that the second task can
> use it using configrefid="foo" or a nested <config refid="foo" />.
>
> I'm not sure how Ivy does it exactly, but somehow I got the feel from
> the discussions that it's using the "deprecated" id'd task pattern,
> which is a "bad" pattern IMHO. Hopefully I got the wrong feeling ;-)

I think we use that bad pattern. We've been wondering about the best form
settings should take for a while. It used to be a datatype in 2.0 alpha, but
we were running into trouble because a datatype has no lifecycle. Hence in a
discussion  Peter suggested to make it a task, using the id as we did before
for the datatype but with a default value:
http://markmail.org/message/52hqry734myzopts

This works pretty well from a user point of view who don't really know if
it's a task or datatype and don't really care. Except that we run into this
bug, and this bad pattern. So, what would you suggest? Is there something we
could do better while still preserving the behaviour we have now?

Xavier

>
>
> --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>


--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Dominique Devienne-2]

On Fri, Mar 28, 2008 at 10:31 AM, Xavier Hanin <xavier.hanin@...> wrote:
> On Fri, Mar 28, 2008 at 4:08 PM, Dominique Devienne <ddevienne@...>
>  > For the record, I think it's bad Ant style to use ids in tasks. [...]
>
>  I think we use that bad pattern. We've been wondering about the best form
>  settings should take for a while. It used to be a datatype in 2.0 alpha, but
>  we were running into trouble because a datatype has no lifecycle. Hence in a
>  discussion  Peter suggested to make it a task, using the id as we did before
>  for the datatype but with a default value:
>  http://markmail.org/message/52hqry734myzopts

Well, reading Gilles original issue, I agree with your answer Xavier.
The "Ant way"(tm) is to have both an id for the <settings> and a
settingsRef in <retrieve>.

The only reason you'd not have a settingsRef in <retrieve> was to be
BC with the deprecated <config> task, and only in this case would you
attempt to use a default id to lookup the settings type. If <config>
was never executed, i.e. you're not in BC mode, lacking a settingsRef
in <retrieve> should be an error right away, and you shouldn't even
try to lookup the "default" id.

If Ivy was designed like most Ant tasks, all 3 forms below would be equivalent:

<retrieve settingsRef="foo" />

<retrieve> <settings ... > ... </settings> </retrieve>

<retrieve> <settings refid="foo" /> </retrieve>

Where the nested settings is equivalent to the "foo" settings type not shown.

The original issue of not being able to error out right away when a
<settings> doesn't have an id is not really an issue IMHO. I'd be OK
with changing Ant to allow a method to be called on types so that they
can self-validate themselves (I also wished for such a method a long
time ago), to enable the failure right at the point of definition of
the type rather than at the point it's used (well, not used in fact,
if you remove the use of a "default" id...).

>  This works pretty well from a user point of view who don't really know if
>  it's a task or datatype and don't really care. Except that we run into this
>  bug, and this bad pattern. So, what would you suggest? Is there something we
>  could do better while still preserving the behaviour we have now?

Well, I don't quite agree here. Even though tasks and types are now
much closer in the core code, they still remain different concepts,
and are documented in separate sections of the manual. Types are data
containers, while tasks are "doers" or actions or verbs. You affect
the behavior of a task using inline stuff (attributes, nested
elements) which can be types, sometimes defined outside the task
itself and simply referenced by id, and the task shouldn't even be
aware whether the types are defined "locally" in the task, or outside.
In fact, you can even id a type defined "inside" a task, and reference
it later by id in another task.

Keeping task ids force the core Ant code to jump thru quite a few
hoops, which we'd better remove in fact... (but we don't for BC...) So
for new code like Ivy, an Ant sub-project even, to be using task ids
is not a good thing in my opinion.

So I suggest you put back settings as a type, only lookup a default id
when you know you are in BC mode (i.e. <config> was used), and
otherwise depend on normal uses and rules for ids and types, allowing
inline-nested definition of settings. Ant users are used to have to id
types they want to refer to in several tasks. Document it as such.
Error out in retrieve when so settings are specified, either inline or
by ref id.

My $0.02. --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Fri, Mar 28, 2008 at 5:14 PM, Dominique Devienne <ddevienne@...>
wrote:

> On Fri, Mar 28, 2008 at 10:31 AM, Xavier Hanin <xavier.hanin@...>
> wrote:
> > On Fri, Mar 28, 2008 at 4:08 PM, Dominique Devienne <ddevienne@...
> >
> >  > For the record, I think it's bad Ant style to use ids in tasks. [...]
> >
> >  I think we use that bad pattern. We've been wondering about the best
> form
> >  settings should take for a while. It used to be a datatype in 2.0alpha, but
> >  we were running into trouble because a datatype has no lifecycle. Hence
> in a
> >  discussion  Peter suggested to make it a task, using the id as we did
> before
> >  for the datatype but with a default value:
> >  http://markmail.org/message/52hqry734myzopts
>
> Well, reading Gilles original issue, I agree with your answer Xavier.
> The "Ant way"(tm) is to have both an id for the <settings> and a
> settingsRef in <retrieve>.
>
> The only reason you'd not have a settingsRef in <retrieve> was to be
> BC with the deprecated <config> task,

Well, it's not fully a BC issue. We could keep the configure task for BC,
and define settings however we want since it's new in 2.0. The problem is
more related to Ivy design. In Ivy original design I tried to make using Ivy
as easy as possible. Hence if you want to use the default settings, and have
an ivy file called ivy.xml in your basedir, then using Ivy is as simple as:
<ivy:retrieve />

I think this has been appreciated by our users from the beginning of Ivy.
Behind the scene, this is roughly equivalent to:
<ivy:configure />
<ivy:resolve />
<ivy:retrieve />

But I don't know if people would complain if we were now using the settings
as any other datatype in the "Ant way". But I think that actually loading
the settings only when they are used is counter intuitive... maybe because
I'm too biased by usage of current Ivy design for more than 3 years now. So
I think this is a difficult design choice: make Ivy more compliant with the
Ant way, or keep a usage as it is used by some people for years, people who
haven't complained about this point yet AFAIR. It's difficult to choose, and
it's probably why we have discussed this so many times so far.

Xavier

[Dominique Devienne-2]

On Fri, Mar 28, 2008 at 11:50 AM, Xavier Hanin <xavier.hanin@...> wrote:

>  [...] In Ivy original design I tried to make using Ivy
>  as easy as possible. Hence if you want to use the default settings, and have
>  an ivy file called ivy.xml in your basedir, then using Ivy is as simple as:
>  <ivy:retrieve />
>
>  I think this has been appreciated by our users from the beginning of Ivy.
>  Behind the scene, this is roughly equivalent to:
>  <ivy:configure />
>  <ivy:resolve />
>  <ivy:retrieve />

This implies the use of a singleton behind the scene, no?

>  But I don't know if people would complain if we were now using the settings
>  as any other datatype in the "Ant way". But I think that actually loading
>  the settings only when they are used is counter intuitive... maybe because
>  I'm too biased by usage of current Ivy design for more than 3 years now. So
>  I think this is a difficult design choice: make Ivy more compliant with the
>  Ant way, or keep a usage as it is used by some people for years, people who
>  haven't complained about this point yet AFAIR. It's difficult to choose, and
>  it's probably why we have discussed this so many times so far.

Hmmm, OK. I don't see why having a <settings> type internally prevents
this simplified use case. Ivy tasks like retrieve with no explicit
settings do then attempt to lookup the well known id for a default
settings, and if not found instantiate the settings type from ivy.xml,
register it using the default id with the project for other tasks to
use, do their business, and that's it.

You implicitly define the settings to support the old use case, but
plug it into the task's addSettings method as if the user had defined
it explicitly, hooking up to the new Ant-way model to pass settings to
Ivy tasks. --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Fri, Mar 28, 2008 at 6:10 PM, Dominique Devienne <ddevienne@...>
wrote:

> On Fri, Mar 28, 2008 at 11:50 AM, Xavier Hanin <xavier.hanin@...>
> wrote:
> >  [...] In Ivy original design I tried to make using Ivy
> >  as easy as possible. Hence if you want to use the default settings, and
> have
> >  an ivy file called ivy.xml in your basedir, then using Ivy is as simple
> as:
> >  <ivy:retrieve />
> >
> >  I think this has been appreciated by our users from the beginning of
> Ivy.
> >  Behind the scene, this is roughly equivalent to:
> >  <ivy:configure />
> >  <ivy:resolve />
> >  <ivy:retrieve />
>
> This implies the use of a singleton behind the scene, no?

Not really. It's just where the default value for id in configure is used.
But it doesn't prevent from defining other instances with other id.

>
>
> >  But I don't know if people would complain if we were now using the
> settings
> >  as any other datatype in the "Ant way". But I think that actually
> loading
> >  the settings only when they are used is counter intuitive... maybe
> because
> >  I'm too biased by usage of current Ivy design for more than 3 years
> now. So
> >  I think this is a difficult design choice: make Ivy more compliant with
> the
> >  Ant way, or keep a usage as it is used by some people for years, people
> who
> >  haven't complained about this point yet AFAIR. It's difficult to
> choose, and
> >  it's probably why we have discussed this so many times so far.
>
> Hmmm, OK. I don't see why having a <settings> type internally prevents
> this simplified use case. Ivy tasks like retrieve with no explicit
> settings do then attempt to lookup the well known id for a default
> settings, and if not found instantiate the settings type from ivy.xml,
> register it using the default id with the project for other tasks to
> use, do their business, and that's it.

You're right. The difference between the task and datatype is mainly when
the settings are loaded. And also how you can use them.


> You implicitly define the settings to support the old use case,

Indeed.

> but
> plug it into the task's addSettings method as if the user had defined
> it explicitly, hooking up to the new Ant-way model to pass settings to
> Ivy tasks. --DD

Yes, you're right. So I agree that to be really clean and follow the Ant
way, settings should be a data type and we should support the three kind of
uses of datatypes you referenced in your earlier e-mail. But this is kind of
a big change in usage, so it's difficult to make such a change now that we
are close to 2.0 final.

Xavier

>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>


--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Dominique Devienne-2]

On Fri, Mar 28, 2008 at 12:40 PM, Xavier Hanin <xavier.hanin@...> wrote:
> On Fri, Mar 28, 2008 at 6:10 PM, Dominique Devienne <ddevienne@...>
>  Yes, you're right. So I agree that to be really clean and follow the Ant
>  way, settings should be a data type and we should support the three kind of
>  uses of datatypes you referenced in your earlier e-mail. But this is kind of
>  a big change in usage, so it's difficult to make such a change now that we
>  are close to 2.0 final.

Sure, it's up to you and the Ivy community to decide what you want to
do. The 3 uses I described are quite easy to implement, and there are
tons of examples in Ant itself. Regarding nearing 2.0 final, I think
it's never too late to do the right thing ;-) Especially when I'm not
the one who has to do it ;-)))

For 2.0 you may just want to make sure you don't have anything that
would prevent you from refactoring the code in the future to support
the better model we discussed. Cheers, --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Maarten Coene]

Can't we just deprecate the "id" attribute on the settings task and use the settingsId attribute instead?

<ivy:settings settingsId="my.settings" />

instead of

<ivy:settings id="my.settings" />

Maarten

----- Original Message ----
From: Xavier Hanin <xavier.hanin@...>
To: Ant Developers List <dev@...>
Sent: Friday, March 28, 2008 4:31:42 PM
Subject: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)

On Fri, Mar 28, 2008 at 4:08 PM, Dominique Devienne <ddevienne@...>
wrote:

> On Fri, Mar 28, 2008 at 8:00 AM, Xavier Hanin <xavier.hanin@...>
> wrote:
> > On Fri, Mar 28, 2008 at 1:23 PM, Gilles Scokart <gscokart@...>
> wrote:
> >  > +1 for me as well (let's put a little bit more presure from the Ivy
> guys ;-).
> >  >
> >  > To come back to the impact on Ivy, I think we should put a note in
> our
> >  > doc saying that using the settings task with an id requires 1.7.1.
> >
> >  We can put a reference to the bug, the problem occurs only when you
> call ant
> >  with multiple targets, each depending on the same settings, so I think
> >  people can use Ivy settings with with ant 1.7.0 without running into
> the
> >  problem.
>
> For the record, I think it's bad Ant style to use ids in tasks. This
> is kept around for BC, but should be discouraged. Using ids on types
> OTOH is OK, and essential to types in fact. If a task should refer to
> part of another task's internal config, this hints to the config
> needing to be its own type referred to by both tasks. It's even OK for
> the type to be implicitly created by the first task, when it receives
> for example a configid="foo" attribute, so that the second task can
> use it using configrefid="foo" or a nested <config refid="foo" />.
>
> I'm not sure how Ivy does it exactly, but somehow I got the feel from
> the discussions that it's using the "deprecated" id'd task pattern,
> which is a "bad" pattern IMHO. Hopefully I got the wrong feeling ;-)

I think we use that bad pattern. We've been wondering about the best form
settings should take for a while. It used to be a datatype in 2.0 alpha, but
we were running into trouble because a datatype has no lifecycle. Hence in a
discussion  Peter suggested to make it a task, using the id as we did before
for the datatype but with a default value:
http://markmail.org/message/52hqry734myzopts

This works pretty well from a user point of view who don't really know if
it's a task or datatype and don't really care. Except that we run into this
bug, and this bad pattern. So, what would you suggest? Is there something we
could do better while still preserving the behaviour we have now?

Xavier

>
>
> --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>


--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/





      ____________________________________________________________________________________
Like movies? Here's a limited-time offer: Blockbuster Total Access for one month at no cost.
http://tc.deals.yahoo.com/tc/blockbuster/text4.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dominique Devienne-2]

On Fri, Mar 28, 2008 at 5:40 PM, Maarten Coene <maarten_coene@...> wrote:
> Can't we just deprecate the "id" attribute on the settings task and use the settingsId attribute instead?

id is handled by Ant itself, in the core. I don't think you can deprecate it.

And that doesn't change the fact that <settings> should be a datatype
rather than a task. --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Fri, Mar 28, 2008 at 11:50 PM, Dominique Devienne <ddevienne@...>
wrote:

> On Fri, Mar 28, 2008 at 5:40 PM, Maarten Coene <maarten_coene@...>
> wrote:
> > Can't we just deprecate the "id" attribute on the settings task and use
> the settingsId attribute instead?
>
> id is handled by Ant itself, in the core. I don't think you can deprecate
> it.

I think we would deprecate the usage we do of id, not really the attribute
itself. And I don't think we even really need to deprecate it, the usage of
id like it is used today has been introduced in 2.0 alphas and betas, so
with no guarantee that it won't change.

>
> And that doesn't change the fact that <settings> should be a datatype
> rather than a task. --DD

I'm still not sure if settings "should" be a datatype. Maybe the name makes
thinks it should be a datatype. If we call it loadsettings instead, I think
it still make sense to make it a task. Exactly as resolve is a task, and
allow with resolveId to set the id of the resolve report it generates and is
later used by other tasks like retrieve. Making resolve a datatype would
really not make any sense IMO, since what people expect when calling is
actually to resolve dependencies. We can consider it's the same thing with
settings/loadsettings. It's kind of similar to the property task when you
use the file attribute: it loads a property file and sets a set of
properties. It has a side effect for other tasks, but it's still a task, not
a datatype.

So maybe renaming settings in loadsettings and renaming id in settingsId
would be a pretty good solution for 2.0: it give us the opportunity to later
add a settings datatype, which loadsettings is only responsible for loading.
And we don't have the 'id' bad usage anymore.

WDYT?

Xavier


>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>


--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Gilles Scokart]

I'm -1 to rename ivy:settings into ivy:loadsettings.  If you realy
want something like that, then it would be better to go back to the
ivy:configure (and I would be -0.5).

The reason I think ivy:settings should be a data-type (or look like a
data type) is because every ant task are "standalone".  I don't know
any example of 2 tasks that should be executed one after the other,
while it is usual to have an ant task depending on a pre-declared
datatype.

An other way to say that is that every tasks are "stateless".  The
only exceptions is the properties task, which for me look like a data
declaration.

That's why Ant is a declarative langage, and not a procedural langage.
 I consider ivy:configure "command" as a procedural command and not a
declarative one.

Now, I agree that the declarative aproach leas to some issues.  One of
them is that the datatype are curently always processed lazily (the
first time they are used) and thus the errors are also reported
lazily, which make the debuging more complex.

Anyway, even if I like the suggestion of Dominique (the user that
don't want to put a settingsRef should use ivy:configure in BC mode),
it has a drawback.  If the user forget to put its settingsRef, he will
not receive any error message, the code will run with the default
settings, even if an other settings is defined.  This lead to problem
difficult to debug.

Gilles


On 29/03/2008, Xavier Hanin <xavier.hanin@...> wrote:

> On Fri, Mar 28, 2008 at 11:50 PM, Dominique Devienne <ddevienne@...>
>  wrote:
>
>
>  > On Fri, Mar 28, 2008 at 5:40 PM, Maarten Coene <maarten_coene@...>
>  > wrote:
>  > > Can't we just deprecate the "id" attribute on the settings task and use
>  > the settingsId attribute instead?
>  >
>  > id is handled by Ant itself, in the core. I don't think you can deprecate
>  > it.
>
>
> I think we would deprecate the usage we do of id, not really the attribute
>  itself. And I don't think we even really need to deprecate it, the usage of
>  id like it is used today has been introduced in 2.0 alphas and betas, so
>  with no guarantee that it won't change.
>
>
>  >
>  > And that doesn't change the fact that <settings> should be a datatype
>  > rather than a task. --DD
>
>
> I'm still not sure if settings "should" be a datatype. Maybe the name makes
>  thinks it should be a datatype. If we call it loadsettings instead, I think
>  it still make sense to make it a task. Exactly as resolve is a task, and
>  allow with resolveId to set the id of the resolve report it generates and is
>  later used by other tasks like retrieve. Making resolve a datatype would
>  really not make any sense IMO, since what people expect when calling is
>  actually to resolve dependencies. We can consider it's the same thing with
>  settings/loadsettings. It's kind of similar to the property task when you
>  use the file attribute: it loads a property file and sets a set of
>  properties. It has a side effect for other tasks, but it's still a task, not
>  a datatype.
>
>  So maybe renaming settings in loadsettings and renaming id in settingsId
>  would be a pretty good solution for 2.0: it give us the opportunity to later
>  add a settings datatype, which loadsettings is only responsible for loading.
>  And we don't have the 'id' bad usage anymore.
>
>  WDYT?
>
>
>  Xavier
>
>
>
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: dev-unsubscribe@...
>  > For additional commands, e-mail: dev-help@...
>  >
>  >
>
>
>
> --
>  Xavier Hanin - Independent Java Consultant
>  http://xhab.blogspot.com/
>  http://ant.apache.org/ivy/
>  http://www.xoocode.org/
>

--
Gilles Scokart

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Sat, Mar 29, 2008 at 7:23 PM, Gilles Scokart <gscokart@...> wrote:

> I'm -1 to rename ivy:settings into ivy:loadsettings.  If you realy
> want something like that, then it would be better to go back to the
> ivy:configure (and I would be -0.5).
>
> The reason I think ivy:settings should be a data-type (or look like a
> data type) is because every ant task are "standalone".  I don't know
> any example of 2 tasks that should be executed one after the other,
> while it is usual to have an ant task depending on a pre-declared
> datatype.

First, if we really want to have all Ivy tasks stateless, we should change
resolve too. The problem is exactly the same between resolve and any post
resolve task as it is between settings and any other task.
Second, I see an example of tasks somewhat depending on one another: taskdef
and any task declared by the taskdef.
So I think loading settings with a task is consistent with resolving
dependencies with a task, and I think it's the only way we have to actually
load the settings when the user wants. If datatype were not lazily
initialized I think I'd be in favour of using a datatype. But with the
current facts I'm not.

Xavier


>
> An other way to say that is that every tasks are "stateless".  The
> only exceptions is the properties task, which for me look like a data
> declaration.

>
> That's why Ant is a declarative langage, and not a procedural langage.
>  I consider ivy:configure "command" as a procedural command and not a
> declarative one.
>
> Now, I agree that the declarative aproach leas to some issues.  One of
> them is that the datatype are curently always processed lazily (the
> first time they are used) and thus the errors are also reported
> lazily, which make the debuging more complex.
>
> Anyway, even if I like the suggestion of Dominique (the user that
> don't want to put a settingsRef should use ivy:configure in BC mode),
> it has a drawback.  If the user forget to put its settingsRef, he will
> not receive any error message, the code will run with the default
> settings, even if an other settings is defined.  This lead to problem
> difficult to debug.
>
> Gilles
>
>
> On 29/03/2008, Xavier Hanin <xavier.hanin@...> wrote:
> > On Fri, Mar 28, 2008 at 11:50 PM, Dominique Devienne <
> ddevienne@...>
> >  wrote:
> >
> >
> >  > On Fri, Mar 28, 2008 at 5:40 PM, Maarten Coene <
> maarten_coene@...>
> >  > wrote:
> >  > > Can't we just deprecate the "id" attribute on the settings task and
> use
> >  > the settingsId attribute instead?
> >  >
> >  > id is handled by Ant itself, in the core. I don't think you can
> deprecate
> >  > it.
> >
> >
> > I think we would deprecate the usage we do of id, not really the
> attribute
> >  itself. And I don't think we even really need to deprecate it, the
> usage of
> >  id like it is used today has been introduced in 2.0 alphas and betas,
> so
> >  with no guarantee that it won't change.
> >
> >
> >  >
> >  > And that doesn't change the fact that <settings> should be a datatype
> >  > rather than a task. --DD
> >
> >
> > I'm still not sure if settings "should" be a datatype. Maybe the name
> makes
> >  thinks it should be a datatype. If we call it loadsettings instead, I
> think
> >  it still make sense to make it a task. Exactly as resolve is a task,
> and
> >  allow with resolveId to set the id of the resolve report it generates
> and is
> >  later used by other tasks like retrieve. Making resolve a datatype
> would
> >  really not make any sense IMO, since what people expect when calling is
> >  actually to resolve dependencies. We can consider it's the same thing
> with
> >  settings/loadsettings. It's kind of similar to the property task when
> you
> >  use the file attribute: it loads a property file and sets a set of
> >  properties. It has a side effect for other tasks, but it's still a
> task, not
> >  a datatype.
> >
> >  So maybe renaming settings in loadsettings and renaming id in
> settingsId
> >  would be a pretty good solution for 2.0: it give us the opportunity to
> later
> >  add a settings datatype, which loadsettings is only responsible for
> loading.
> >  And we don't have the 'id' bad usage anymore.
> >
> >  WDYT?
> >
> >
> >  Xavier
> >
> >
> >
> >  >
> >  >
> >  > ---------------------------------------------------------------------
> >  > To unsubscribe, e-mail: dev-unsubscribe@...
> >  > For additional commands, e-mail: dev-help@...
> >  >
> >  >
> >
> >
> >
> > --
> >  Xavier Hanin - Independent Java Consultant
> >  http://xhab.blogspot.com/
> >  http://ant.apache.org/ivy/
> >  http://www.xoocode.org/
> >
>
>
> --
> Gilles Scokart
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

[Maarten Coene]

I don't think the tasks should be stateless, I think it's fine the way it is now.
There are other examples of tasks that must be executed one ofther the other, like:
setProxy -> must be executed before outgoing http connections are made if you have a proxy
the Clover tasks -> the setup task must be executed first
junitreport -> is sharing state with the junit tasks through xml files, a bit the same as the postresolve task can share state with the resolve task by parsing the XML resolve report.

If we keep ivy:settings to be a task, we should do 2 things:
- rename the "id" attribute to something else
- rename "ivy:settings" to something else to make it more clear what it does to avoid confusion. But I think Gilles has a point here about the ivy:configure task. I don't see a difference between the "ivy:settings" task and the "ivy:configure" task, except the ability to specify a settings id.

So, I think we should do the following:
1. undeprecate the "ivy:configure" task and add a settingsId attribute to it (and the other settings attributes that aren't present on ivy:configure)
2. undefine the "ivy:settings" task (just remove it from the antlib.xml)
3. refactor the IvyAntSettingsTask (or whatever it's name is) to be a real datatype, which will be created internally by ivy:configure and used in all the other Ivy tasks. But don't make this datatype available for usage in the ant scripts yet. This way, it will be easy to support the use-case of lazy-loading the Ivy settings once we think it's usefull to support it.

Maarten


----- Original Message ----
From: Xavier Hanin <xavier.hanin@...>
To: Ant Developers List <dev@...>
Sent: Sunday, March 30, 2008 5:52:39 PM
Subject: Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)

On Sat, Mar 29, 2008 at 7:23 PM, Gilles Scokart <gscokart@...> wrote:

> I'm -1 to rename ivy:settings into ivy:loadsettings.  If you realy
> want something like that, then it would be better to go back to the
> ivy:configure (and I would be -0.5).
>
> The reason I think ivy:settings should be a data-type (or look like a
> data type) is because every ant task are "standalone".  I don't know
> any example of 2 tasks that should be executed one after the other,
> while it is usual to have an ant task depending on a pre-declared
> datatype.

First, if we really want to have all Ivy tasks stateless, we should change
resolve too. The problem is exactly the same between resolve and any post
resolve task as it is between settings and any other task.
Second, I see an example of tasks somewhat depending on one another: taskdef
and any task declared by the taskdef.
So I think loading settings with a task is consistent with resolving
dependencies with a task, and I think it's the only way we have to actually
load the settings when the user wants. If datatype were not lazily
initialized I think I'd be in favour of using a datatype. But with the
current facts I'm not.

Xavier


>
> An other way to say that is that every tasks are "stateless".  The
> only exceptions is the properties task, which for me look like a data
> declaration.

>
> That's why Ant is a declarative langage, and not a procedural langage.
>  I consider ivy:configure "command" as a procedural command and not a
> declarative one.
>
> Now, I agree that the declarative aproach leas to some issues.  One of
> them is that the datatype are curently always processed lazily (the
> first time they are used) and thus the errors are also reported
> lazily, which make the debuging more complex.
>
> Anyway, even if I like the suggestion of Dominique (the user that
> don't want to put a settingsRef should use ivy:configure in BC mode),
> it has a drawback.  If the user forget to put its settingsRef, he will
> not receive any error message, the code will run with the default
> settings, even if an other settings is defined.  This lead to problem
> difficult to debug.
>
> Gilles
>
>
> On 29/03/2008, Xavier Hanin <xavier.hanin@...> wrote:
> > On Fri, Mar 28, 2008 at 11:50 PM, Dominique Devienne <
> ddevienne@...>
> >  wrote:
> >
> >
> >  > On Fri, Mar 28, 2008 at 5:40 PM, Maarten Coene <
> maarten_coene@...>
> >  > wrote:
> >  > > Can't we just deprecate the "id" attribute on the settings task and
> use
> >  > the settingsId attribute instead?
> >  >
> >  > id is handled by Ant itself, in the core. I don't think you can
> deprecate
> >  > it.
> >
> >
> > I think we would deprecate the usage we do of id, not really the
> attribute
> >  itself. And I don't think we even really need to deprecate it, the
> usage of
> >  id like it is used today has been introduced in 2.0 alphas and betas,
> so
> >  with no guarantee that it won't change.
> >
> >
> >  >
> >  > And that doesn't change the fact that <settings> should be a datatype
> >  > rather than a task. --DD
> >
> >
> > I'm still not sure if settings "should" be a datatype. Maybe the name
> makes
> >  thinks it should be a datatype. If we call it loadsettings instead, I
> think
> >  it still make sense to make it a task. Exactly as resolve is a task,
> and
> >  allow with resolveId to set the id of the resolve report it generates
> and is
> >  later used by other tasks like retrieve. Making resolve a datatype
> would
> >  really not make any sense IMO, since what people expect when calling is
> >  actually to resolve dependencies. We can consider it's the same thing
> with
> >  settings/loadsettings. It's kind of similar to the property task when
> you
> >  use the file attribute: it loads a property file and sets a set of
> >  properties. It has a side effect for other tasks, but it's still a
> task, not
> >  a datatype.
> >
> >  So maybe renaming settings in loadsettings and renaming id in
> settingsId
> >  would be a pretty good solution for 2.0: it give us the opportunity to
> later
> >  add a settings datatype, which loadsettings is only responsible for
> loading.
> >  And we don't have the 'id' bad usage anymore.
> >
> >  WDYT?
> >
> >
> >  Xavier
> >
> >
> >
> >  >
> >  >
> >  > ---------------------------------------------------------------------
> >  > To unsubscribe, e-mail: dev-unsubscribe@...
> >  > For additional commands, e-mail: dev-help@...
> >  >
> >  >
> >
> >
> >
> > --
> >  Xavier Hanin - Independent Java Consultant
> >  http://xhab.blogspot.com/
> >  http://ant.apache.org/ivy/
> >  http://www.xoocode.org/
> >
>
>
> --
> Gilles Scokart
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/





      ____________________________________________________________________________________
Like movies? Here's a limited-time offer: Blockbuster Total Access for one month at no cost.
http://tc.deals.yahoo.com/tc/blockbuster/text4.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Xavier Hanin]

On Mon, Mar 31, 2008 at 1:36 PM, Maarten Coene <maarten_coene@...>
wrote:

> I don't think the tasks should be stateless, I think it's fine the way it
> is now.
> There are other examples of tasks that must be executed one ofther the
> other, like:
> setProxy -> must be executed before outgoing http connections are made if
> you have a proxy
> the Clover tasks -> the setup task must be executed first
> junitreport -> is sharing state with the junit tasks through xml files, a
> bit the same as the postresolve task can share state with the resolve task
> by parsing the XML resolve report.
>
> If we keep ivy:settings to be a task, we should do 2 things:
> - rename the "id" attribute to something else
> - rename "ivy:settings" to something else to make it more clear what it
> does to avoid confusion. But I think Gilles has a point here about the
> ivy:configure task. I don't see a difference between the "ivy:settings" task
> and the "ivy:configure" task, except the ability to specify a settings id.
>
> So, I think we should do the following:
> 1. undeprecate the "ivy:configure" task and add a settingsId attribute to
> it (and the other settings attributes that aren't present on ivy:configure)
> 2. undefine the "ivy:settings" task (just remove it from the antlib.xml)
> 3. refactor the IvyAntSettingsTask (or