On 6/25/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
2007/6/25, Xavier Hanin <[EMAIL PROTECTED]>: > > By the way, note that writting <ivy:settings/> actually doesn't do > > anything. Your resolve will indeed use the default settings, but not > > because of your declaration of <ivy:settings/>. What will happen in > > the resolve is that the task will search for the default id > > "ivy.instance", and will not found anything. In that case, it creates > > this default settings and will use it. > > > I think this is counter intuitive. Why the <ivy:settings /> doesn't use the > default id used by the resolve? Or maybe I'm missing something? > > Xavier > It is counter intuitive for people migrating from 1.4, I agree. It's because ivy:settings is a ant datatype, and there is no way to way to hook the code that register himself with a default id. A work around might be to make it a Task instead of a dataype. That would allow to implement what you describe.
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. Using a task is like what we did in 1.x. The only cons I see is that we can't use the syntax given as example above. But maybe we could take advantage of both options, by avoiding the deprecation of the configure task. In this case we would have the two options: use a datatype (settings), or a task (configure). But maybe this would be more confusing? Opinions? Xavier --
Gilles SCOKART
-- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/
