ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: [Ant2] Tasks as siblings of <target>
Date Thu, 25 Oct 2001 07:25:10 GMT
From: "Tim Dawson" <tdawson@wamnet.com>

> Jose Alberto writes:
> > I do not think we should tie location of tasks with 
> > priviledge. For example
> > <property> does not need more priviledges than <available>, they both
> > just set the value of properties. However we like one at 
> > project level and the other not.
> 
> Why exactly is that? if you're setting a property with <available> it seems
> perfectly reasonable to be able to do that at the top level if that sort of
> thing is to be allowed.  As an Ant user, I'm at the mercy of the Ant core
> authors as to whether or not I can define this at the top (thereby making it
> available to all targets) or whether I have to do a bunch of dependencies on
> each and every target.
> 

Oh, I knew my example would stir the <available> pot. ;-)
I have no idea why <available> is the way it is. I have heard people complaining
and heard others defending it. I think the reason includes in part not wanting to have more
names hardcoded on the parser 8-/

In any case the discussion of what should be allowed where is a different one.
I am just advocating the means to be able to have such discussion.

> That said, I can *almost* buy off on the concept of putting <taskdef> and
> <property> (and <available> and other "tasks that declare things" at the
top
> level IF you're talking about implementing real scoping, i.e. if doing
> <taskdef> and <property> inside a target means it is no longer available
> outside that target.
> 

I do not think we are advocating <target> as a separate scope. Since we still
need to be able to set properties based on how the build process goes. Project-level
is executed before the build target are run.

Jose Alberto




Mime
View raw message