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 16:12:01 GMT
On 6/25/07, Gilles Scokart <gscokart@gmail.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: lundi 25 juin 2007 16:47
> > 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:
> > >
> > > 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?
>
> Currently on the trunk, yes, you are right.  I just said that it didn't
> make
> sense, so for me it could raise an error or we could keep the current
> behaviour.  I'm too tired today to say which approach I would prefer.
>
> >
> > - 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?
> >
>
> Currently on the trunk, again you are right.  But I'm not sure it is
> intuitive.  I would prefer the second resolve call trigger an error saying
> that the ivy:settings must have an id.



To do so we'd need to make configure really different, initializing a
settings that wouldn't be accessible by tasks using settingsRef, right? I'm
not sure to know which option I prefer. What I don't like with this approach
is that we deprecate a task and make the new mechanism really different,
where you always need to specify an id. But people who don't need scoping
(probably most users) don't really care about this id.

So I think I prefer to avoid deprecation of configure, and document it as
being a task creating a settings datatype, that's all. With a default value
for the id. Then people used to Ivy 1.x won't get lost, and people who want
to understand the mechanism underneath should be able to understand without
too much trouble that a settings is an object that you can either define
using the settings datatype, or using a configure task. With examples of
what you can do with the datatype and what you can do with the task. But I'm
getting tired too so maybe my judgment is biased :-)

Xavier

Gilles
>
>


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