On 11/28/06, Gilles Scokart <[EMAIL PROTECTED]> 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
