ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
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 14:26:45 GMT
I think I was not clear in my explanations, sorry.
What I would like to have is :

- When deprecated <configure> is used, no scoping is available.  settingsRef
in task doesn't make sense
- When a <settings> is defined, id='...' is mandatory.  And an error (with a
clear message) is triggered when a task try to use the settings
'ivy.instance' (implicitely or or not) and this instance was created with a
<settings> without id.
- When no <settings> and no <configure> are used and a task doesn't set the
settingRef, a default settings will be created.


Gilles


> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: lundi 25 juin 2007 14:50
> To: ivy-user@incubator.apache.org
> 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)?)
> 
> On 6/25/07, Gilles Scokart <gscokart@gmail.com> 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.
> >
> > WDYT?
> 
> 
> 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
> 
> Gilles
> >
> >
> 
> 
> --
> Xavier Hanin - Independent Java Consultant
> Manage your dependencies with Ivy!
> http://incubator.apache.org/ivy/


Mime
View raw message