ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <>
Subject Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
Date Sat, 29 Mar 2008 17:23:55 GMT
I'm -1 to rename ivy:settings into ivy:loadsettings.  If you realy
want something like that, then it would be better to go back to the
ivy:configure (and I would be -0.5).

The reason I think ivy:settings should be a data-type (or look like a
data type) is because every ant task are "standalone".  I don't know
any example of 2 tasks that should be executed one after the other,
while it is usual to have an ant task depending on a pre-declared

An other way to say that is that every tasks are "stateless".  The
only exceptions is the properties task, which for me look like a data

That's why Ant is a declarative langage, and not a procedural langage.
 I consider ivy:configure "command" as a procedural command and not a
declarative one.

Now, I agree that the declarative aproach leas to some issues.  One of
them is that the datatype are curently always processed lazily (the
first time they are used) and thus the errors are also reported
lazily, which make the debuging more complex.

Anyway, even if I like the suggestion of Dominique (the user that
don't want to put a settingsRef should use ivy:configure in BC mode),
it has a drawback.  If the user forget to put its settingsRef, he will
not receive any error message, the code will run with the default
settings, even if an other settings is defined.  This lead to problem
difficult to debug.


On 29/03/2008, Xavier Hanin <> wrote:
> On Fri, Mar 28, 2008 at 11:50 PM, Dominique Devienne <>
>  wrote:
>  > 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.
>  WDYT?
>  Xavier
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail:
>  > For additional commands, e-mail:
>  >
>  >
> --
>  Xavier Hanin - Independent Java Consultant

Gilles Scokart

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

View raw message