ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
Date Mon, 31 Mar 2008 13:53:54 GMT
For the record, I'm -0.5 to the plan of Maarten.

I think settings should looks like a datatype (and maybe resolve as
well), but I don't find any good aproach to do it.  The changes would
be too big.  So I don't see a better plan than the one presented by
Maarten.

If someone has a better plan, please talk.

Concerning the name, I would preffer to stick to configure if we don't
move to a datatype.  I don't think that configuring ivy using a
settings file will be confused with the dependency configurations.

Gilles

On 31/03/2008, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> 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/
>


-- 
Gilles Scokart

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message