ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
Date Fri, 28 Mar 2008 17:40:11 GMT
On Fri, Mar 28, 2008 at 6:10 PM, Dominique Devienne <>

> On Fri, Mar 28, 2008 at 11:50 AM, Xavier Hanin <>
> wrote:
> >  [...] In Ivy original design I tried to make using Ivy
> >  as easy as possible. Hence if you want to use the default settings, and
> have
> >  an ivy file called ivy.xml in your basedir, then using Ivy is as simple
> as:
> >  <ivy:retrieve />
> >
> >  I think this has been appreciated by our users from the beginning of
> Ivy.
> >  Behind the scene, this is roughly equivalent to:
> >  <ivy:configure />
> >  <ivy:resolve />
> >  <ivy:retrieve />
> This implies the use of a singleton behind the scene, no?

Not really. It's just where the default value for id in configure is used.
But it doesn't prevent from defining other instances with other id.

> >  But I don't know if people would complain if we were now using the
> settings
> >  as any other datatype in the "Ant way". But I think that actually
> loading
> >  the settings only when they are used is counter intuitive... maybe
> because
> >  I'm too biased by usage of current Ivy design for more than 3 years
> now. So
> >  I think this is a difficult design choice: make Ivy more compliant with
> the
> >  Ant way, or keep a usage as it is used by some people for years, people
> who
> >  haven't complained about this point yet AFAIR. It's difficult to
> choose, and
> >  it's probably why we have discussed this so many times so far.
> Hmmm, OK. I don't see why having a <settings> type internally prevents
> this simplified use case. Ivy tasks like retrieve with no explicit
> settings do then attempt to lookup the well known id for a default
> settings, and if not found instantiate the settings type from ivy.xml,
> register it using the default id with the project for other tasks to
> use, do their business, and that's it.

You're right. The difference between the task and datatype is mainly when
the settings are loaded. And also how you can use them.

> You implicitly define the settings to support the old use case,


> but
> plug it into the task's addSettings method as if the user had defined
> it explicitly, hooking up to the new Ant-way model to pass settings to
> Ivy tasks. --DD

Yes, you're right. So I agree that to be really clean and follow the Ant
way, settings should be a data type and we should support the three kind of
uses of datatypes you referenced in your earlier e-mail. But this is kind of
a big change in usage, so it's difficult to make such a change now that we
are close to 2.0 final.


> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Xavier Hanin - Independent Java Consultant

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