ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
Date Mon, 31 Mar 2008 12:40:47 GMT
On Mon, Mar 31, 2008 at 1:36 PM, Maarten Coene <maarten_coene@yahoo.com>
wrote:

> I don't think the tasks should be stateless, I think it's fine the way it
> is now.
> There are other examples of tasks that must be executed one ofther the
> other, like:
> setProxy -> must be executed before outgoing http connections are made if
> you have a proxy
> the Clover tasks -> the setup task must be executed first
> junitreport -> is sharing state with the junit tasks through xml files, a
> bit the same as the postresolve task can share state with the resolve task
> by parsing the XML resolve report.
>
> If we keep ivy:settings to be a task, we should do 2 things:
> - rename the "id" attribute to something else
> - rename "ivy:settings" to something else to make it more clear what it
> does to avoid confusion. But I think Gilles has a point here about the
> ivy:configure task. I don't see a difference between the "ivy:settings" task
> and the "ivy:configure" task, except the ability to specify a settings id.
>
> So, I think we should do the following:
> 1. undeprecate the "ivy:configure" task and add a settingsId attribute to
> it (and the other settings attributes that aren't present on ivy:configure)
> 2. undefine the "ivy:settings" task (just remove it from the antlib.xml)
> 3. refactor the IvyAntSettingsTask (or whatever it's name is) to be a real
> datatype, which will be created internally by ivy:configure and used in all
> the other Ivy tasks. But don't make this datatype available for usage in the
> ant scripts yet. This way, it will be easy to support the use-case of
> lazy-loading the Ivy settings once we think it's usefull to support it.

I mostly agree with this plan. The only thing I'm still wondering about is
if naming the task "configure" is a good idea. We have renamed configuration
files to settings files everywhere to avoid the confusion. Calling the task
configure may reintroduce some confusion. So I'd prefer another name, like
loadsettings or setup.

Xavier


>
>
> Maarten
>
>
> ----- Original Message ----
> From: Xavier Hanin <xavier.hanin@gmail.com>
> To: Ant Developers List <dev@ant.apache.org>
> Sent: Sunday, March 30, 2008 5:52:39 PM
> Subject: Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7branch?)
>
> On Sat, Mar 29, 2008 at 7:23 PM, Gilles Scokart <gscokart@gmail.com>
> wrote:
>
> > 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
> > datatype.
>
> First, if we really want to have all Ivy tasks stateless, we should change
> resolve too. The problem is exactly the same between resolve and any post
> resolve task as it is between settings and any other task.
> Second, I see an example of tasks somewhat depending on one another:
> taskdef
> and any task declared by the taskdef.
> So I think loading settings with a task is consistent with resolving
> dependencies with a task, and I think it's the only way we have to
> actually
> load the settings when the user wants. If datatype were not lazily
> initialized I think I'd be in favour of using a datatype. But with the
> current facts I'm not.
>
> Xavier
>
>
> >
> > 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
> > declaration.
>
>
> >
> > 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.
> >
> > Gilles
> >
> >
> > On 29/03/2008, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> > > On Fri, Mar 28, 2008 at 11:50 PM, Dominique Devienne <
> > ddevienne@gmail.com>
> > >  wrote:
> > >
> > >
> > >  > On Fri, Mar 28, 2008 at 5:40 PM, Maarten Coene <
> > maarten_coene@yahoo.com>
> > >  > 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: dev-unsubscribe@ant.apache.org
> > >  > For additional commands, e-mail: dev-help@ant.apache.org
> > >  >
> > >  >
> > >
> > >
> > >
> > > --
> > >  Xavier Hanin - Independent Java Consultant
> > >  http://xhab.blogspot.com/
> > >  http://ant.apache.org/ivy/
> > >  http://www.xoocode.org/
> > >
> >
> >
> > --
> > Gilles Scokart
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
>
>
>
>
>
>  ____________________________________________________________________________________
> Like movies? Here's a limited-time offer: Blockbuster Total Access for one
> month at no cost.
> http://tc.deals.yahoo.com/tc/blockbuster/text4.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

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