ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Ivy settings management from Ant (was Re: can i call ivy:configure multiple times with different configuration files(which in turn refers different ivy.xmls)?)
Date Mon, 25 Jun 2007 12:49:57 GMT
On 6/25/07, Gilles Scokart <> wrote:
> >
> > OK, I understand. Could we list the pros and cons of each solution and
> see
> > what's the best solution. The pros I see for a datatype is that we could
> > use
> > it directly in tasks requiring a settings. For instance:
> > <ivy:resolve file="ivy.xml">
> >   <ivy:settings url="http://myserver/ivysettings.xml"/>
> > </ivy:resolve>
> >
> > I like this option. For people comfortable with ant datatypes, it should
> > be
> > clear.
> > The cons is that it's counter intuitive for Ivy 1.x users, and not
> obvious
> > for others. It makes the scoping mandatory.
> The scoping is not really mandatory.  It is only mandatory in the
> declaration of the settings.  The other task can still reference
> 'ivy.instance' by default.

Yes, but I feel like this is awkward from a user point of view: there is a
default value for the id everywhere but in the settings declaration. I'd
prefer a default everywhere or nowhere.

I'm just thinking to an other approach.  I'm not sure it is clean or even
> will work, but it might be a possible workaround.
> We could overwrite the setProject and write a setId method.  When
> setProject
> is called first (I think it is normally the case), we could register the
> instance with the id 'ivy.instance' (of this reference is not yet used).
> Then, in the setId, we remove the previously registered reference.
> With this hack, you could make the id optional on ivy:settings, but I
> don't
> think it's a good idea because it will not be intuitive that's a datatype.
> I would rather make the settings of the id really mandatory in
> settings.  If
> we use the same hack (overwrite setProject and setId), we could register a
> unusable settings behind 'ivy.instance' when there is no id that report an
> error when used.

Why not, but this means that we make the settings initialization mandatory,
which was not the case in 1.x. I like the idea of having good defaults to
make the first use of Ivy as easy as possible. What I don't like with the
new approach is that you need to specify an id in settings, not in post
settings tasks, and that there is no error when you don't specify an id. But
I see no way to raise an error without id, because using settings without id
is allowed in a post settings task (like resolve).

So I would really appreciate feedback from users on this subject. My
preference for the moment still goes to undeprecating the configure task.



Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message