ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <>
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:31:35 GMT
> 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.

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.


View raw message