On 10/24/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> 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>
One can use a task as a type here.
- for example in Ant, available is a type and a task.
Peter
> 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.
However, I would think that 99% of projects would only have a single setting.
Peter
>
> 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/
>
