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?
- Can we generate an error if no ids are given?
- 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
