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? > 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 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
