On Fri, Mar 28, 2008 at 6:10 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 28, 2008 at 11:50 AM, Xavier Hanin <[EMAIL PROTECTED]> > 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, Indeed. > 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. Xavier > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/