ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@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:47:20 GMT
On 6/25/07, Gilles Scokart <gscokart@gmail.com> wrote:
>
> 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


Does it mean that if you use settingsRef in a task it will raise an error?
Even if you use settingsRef="ivy.instance"? I thought the call to configure
with no id was equivalent to <ivy:settings id="ivy.instance"/>. Is it right?

- 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.


Sorry, I'm not sure to fully understand this point. Do you mean that:
<ivy:settings />
<ivy:resolve settingsRef="ivy.instance" />
will raise a clear error, saying that the id is mandatory in settings?

In this case, what happen if you do this:
<ivy:configure file="ivyconf.xml"/>
<ivy:resolve />
<ivy:settings file="ivysettings.xml" />
<ivy:resolve settingsRef="ivy.instance" />
?
The first resolve should run ok with the settings loaded from ivyconf.xml.
Then will the second resolve use the first settings loaded with configure,
the second one, or raise an error? My guess is that it will use the first
settings. Am I right?


- When no <settings> and no <configure> are used and a task doesn't set the
> settingRef, a default settings will be created.


Sounds fine.

Xavier

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/
>
>


-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

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