> 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
> - 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
