Statefull or not statefull ?

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

A few days ago, we discuss about some regrets/enhancement/things that
looked strange for a new user.

We mention the confusion between 'configuration' and 'configuration'.

I remember that when I started to use ivy, an other thing surprized me
: the statefullness of the task.

Indeed, in all the ant task that I know, it is rather unusual to have
tasks behavior depending on the previous execution of an other task
like it is done in ivy.  Usually, the 'state' of a build is either a
state on the file system or some highly visible properties/id defined
(by highly visible, I means properties/id name choosen and coded by
the user).

Actually, I would have expected to have a type 'ivy-engine' with an
id, referenced in all ivy tasks  (except when the default
configuration is used).  I would also have expected to have a
'resolution' type, with and id referenced in the post resolve task.  A
priory, I would have found it more natural.

Anyway, once you are used to it, this point is probably not very
important.  It was just my first feeling when I started to use ivy a
few months ago that I wanted to share.

Best Regards,

Gilles

Re: Statefull or not statefull ?

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

On 11/28/06, Gilles Scokart <gs...@gmail.com> wrote:
>
> A few days ago, we discuss about some regrets/enhancement/things that
> looked strange for a new user.
>
> We mention the confusion between 'configuration' and 'configuration'.
>
> I remember that when I started to use ivy, an other thing surprized me
> : the statefullness of the task.
>
> Indeed, in all the ant task that I know, it is rather unusual to have
> tasks behavior depending on the previous execution of an other task
> like it is done in ivy.  Usually, the 'state' of a build is either a
> state on the file system or some highly visible properties/id defined
> (by highly visible, I means properties/id name choosen and coded by
> the user).
>
> Actually, I would have expected to have a type 'ivy-engine' with an
> id, referenced in all ivy tasks  (except when the default
> configuration is used).  I would also have expected to have a
> 'resolution' type, with and id referenced in the post resolve task.  A
> priory, I would have found it more natural.
>
> Anyway, once you are used to it, this point is probably not very
> important.  It was just my first feeling when I started to use ivy a
> few months ago that I wanted to share.


Thanks for sharing this feeling. It may make sense to review the process, at
least to make the object passed from one task to another more visible, even
maybe with the possibility to define the id to use, so that users could more
easily do several non related Ivy tasks in the same build. For the moment
it's a little bit difficult to address properly, especially with
1.4feature, if you want to create a classpath using Ivy for an ant
task, and
then do a retrieve for the main module, or stuff like that.

Xavier

Best Regards,
>
> Gilles
>