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.
- if the default file is not there, is there a default settings within ivy ?
>
> 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);
}
}
>
> 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
>
