On 10/25/07, Jacob Grydholt Jensen <[EMAIL PROTECTED]> wrote:
>
> > 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".
>
> Okay I tried the tutorial yesterday and opened IVY-629 since I
> observed this behaviour. Without the id, ivy will just use the default
> settings from the ivy.jar as explained by Xavier.
>
> > But, are we happy with this?
> > - Can we generate an error if no ids are given?
>
> I would like the following:
>
> - if the user provides no ivysettings, a default setting is read
> from the ivy.jar and assigned the default id. I think this is how ivy
> works today.
> - if the user provides exactly one ivysettings without an id, the
> default id is assigned to the ivysettings behind the scenes.
> - if the user provides more than one ivysettings without an id, it
> is considered an error
This sounds like a good approach, could we do that with a datatype?
Xavier
> - Should we un-deprecate ivy:configure for the users that don't want to
> use
> > multiple settings?
>
> I agree with Xavier that it would be unwise to continue to support two
> different ways of setting up ivy.
>
> /grydholt
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
