On 10/24/07, Peter Reilly <[EMAIL PROTECTED]> wrote:
>
> 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.
Ok, thanks for the tip. So this is not an argument against ivy:settings
being a task rather than a datatype. So I'm fine if we make it a task, but
I'd prefer keeping a datatype with the default value for the id.
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.
Until 2.x it wasn't even possible to have multiple settings, so your ratio
is probably right :-)
Xavier
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/
> >
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
