On 10/24/07, Peter Reilly <[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>
> I do not know much about ivy...
> But:
> - does it have a default location for the ivysetting.xml file.
Yes: "ivyconf.xml" in either the project basedir or the current directory. I
think it should be "ivysettings.xml" now (and keep "ivyconf.xml" for
backward compatibility). You can also set ivy.settings.file property to set
another default location.
- if the default file is not there, is there a default settings within ivy
> ?
Yes.
>
> > 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".
>
> One could make ivy:settings a task. One can use setId, and
> the id will still work ok. However I would suggest doing something like:
>
> public class Settings extends Task {
> private String id = "ivy.instance";
> public void setId(String id) { this.id = id; }
> public void execute() {
> getProject().addReference(id, this);
> }
> }
This sounds like a good idea to me.
Xavier
>
> > But, are we happy with this?
> > - Can we generate an error if no ids are given?
> I would suggest having a default.
>
> Peter
> > - 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' ?
> > - Should we un-deprecate ivy:configure for the users that don't want to
> use
> > multiple settings?
> >
> >
> > --
> > Gilles SCOKART
> >
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
