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 Sat, 29 Mar 2008 08:51:01 GMT
On Fri, Mar 28, 2008 at 11:50 PM, Dominique Devienne <>

> On Fri, Mar 28, 2008 at 5:40 PM, Maarten Coene <>
> wrote:
> > Can't we just deprecate the "id" attribute on the settings task and use
> the settingsId attribute instead?
> id is handled by Ant itself, in the core. I don't think you can deprecate
> it.

I think we would deprecate the usage we do of id, not really the attribute
itself. And I don't think we even really need to deprecate it, the usage of
id like it is used today has been introduced in 2.0 alphas and betas, so
with no guarantee that it won't change.

> And that doesn't change the fact that <settings> should be a datatype
> rather than a task. --DD

I'm still not sure if settings "should" be a datatype. Maybe the name makes
thinks it should be a datatype. If we call it loadsettings instead, I think
it still make sense to make it a task. Exactly as resolve is a task, and
allow with resolveId to set the id of the resolve report it generates and is
later used by other tasks like retrieve. Making resolve a datatype would
really not make any sense IMO, since what people expect when calling is
actually to resolve dependencies. We can consider it's the same thing with
settings/loadsettings. It's kind of similar to the property task when you
use the file attribute: it loads a property file and sets a set of
properties. It has a side effect for other tasks, but it's still a task, not
a datatype.

So maybe renaming settings in loadsettings and renaming id in settingsId
would be a pretty good solution for 2.0: it give us the opportunity to later
add a settings datatype, which loadsettings is only responsible for loading.
And we don't have the 'id' bad usage anymore.



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

Xavier Hanin - Independent Java Consultant

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