On 10/24/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
>
> I just run the tutorial chainresolvers, and it is failing because of a
> problem related to ivy:settings / ivy:configure.
>
> Before I explain the problem in the tutorial, let me replace this in its
> context.
>
> In 1.4 and before, the user could configure ivy using the task
> ivy:configure? This task was actually setting up the ivy engine that were
> used in all subsequent ivy tasks.
>
> Since 2.0 (I don't remind me exactly which alpha release) we have
> introduced
> ivy:settings. We did that for at least 3 reasons:
> - The name settings was preffered to config because configuration means
> something else
> - It is not 'natural' for an ant task to have a behavior depending on the
> execution of an other ant task before (the only exception I think concerns
> the properties)
> - We wanted to allow to have multiple settings that could be used in the
> same script (or sub-script)
>
> We already had various discussion on wether ivy:configure should be
> deprecated or not, and wether ivy:settings should be a task or a datatype.
>
> The situation now is that :
> - ivy:settings is a datatype, for which the documentation say that the id
> is
> mandatory.
> - ivy:configure is documented as deprecated (and print a warning message
> if
> you use it). It actually register it as an ivy:settings with the id
> ivy.instance.
> - All other ivy task have an optional settingsRef attribute. When it is
> not
> specified, the settings ivy.instance is used (or a default one if none
> exists)
>
>
> Now, the bug in the tutorial.
>
> Here is an exctract:
> <ivy:settings file="${ivy.settings.dir}/ivysettings.xml" />
> <target name="resolve" description="--> retreive dependencies with
> ivy">
> <ivy:retrieve/>
> </target>
>
> This actually fails because the retrieve task will use the default
> settings. Indeed, the ivy:retrieve will use the settings with the id '
> ivy.instance', which doesn't exist!
> Because ivy:settings is a datatype, he can not check that an id is defined
> (even if the intention was to make it mandatory).
>
> To fix it I will add the id="ivy.instance".
>
> But, are we happy with this?
I'm not really. IMO in the tutorial we should either use an explicit id for
both settings AND retrieve, or don't set the id in both. I'm fine with the
former, the latter is not currently possible.
- Can we generate an error if no ids are given?
This would be nice, but I don't know.
- Should we make ivy:settings a task that looks like a datatype in order to
> check that the id is set? And in that case, can we still use the
> attribute
> 'id' ?
In that case I don't think we could be using the 'id' attribute, it was
causing problem in a very early release of Ivy (0.x). I don't really like
making a task looks like a datatype, and this would prevent construct like:
<ivy:retrieve ...>
<ivy:settings file="..."/>
</ivy:retrieve>
which I personally like (but we don't support it yet).
I'd prefer either sticking with a datatype, or make it a task which sounds
like a task.
- Should we un-deprecate ivy:configure for the users that don't want to use
> multiple settings?
I don't know: OOH it would be more simple for Ivy 1.x users, and for many
users who don't care about multiple settings; OTOH, we'd have two ways to
load settings, which is a not a very good thing. And the advantage of making
the settings id mandatory is that it forces the understanding of how
multiple settings can be used.
So I think I'll follow others' opinion...
Xavier
--
> Gilles SCOKART
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
