ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Rosenberg" <ja...@squaretrade.com>
Subject Re: Property substitutions, Contributed Tasks, & New features
Date Fri, 12 Jan 2001 17:41:25 GMT

----- Original Message ----- 
From: "James Duncan Davidson" <duncan@x180.net>
To: <ant-dev@jakarta.apache.org>
Sent: Friday, January 12, 2001 1:10 AM
Subject: Re: Property substitutions, Contributed Tasks, & New features


> On 1/8/01 11:33 AM, "Jason Rosenberg" <jason@squaretrade.com> wrote:
> 
> > I think, in general, we need to be explicit about the
> > several different kinds of property semantics, and perhaps
> > they all should be allowed and supported, but specified
> > with different syntax or attributes.
> > 
> > The property types:
> > 
> > 1.  run-time evaluated, not-resettable.
> >   This is the current <property> behavior in Ant 1.2.  Once set, it cannot
be
> > changed.
> 
> Not good. If full scripting semantics are to be exported, this is bad.
> 

I agree, I was just thinking that since this is how it is in 1.2, there must have
been a reason and desire for it, so perhaps there are those who would argue
that it is necessary....

> > 2. run-time evaluated, resettable.
> 
> This is the way that properties were meant to be.
> 

amen

> > 3. parse-time evaluated, not-resettable.
> >   These would be defined at parse time, and remain immutable at run-time.
> >   Could use a <constant-property> task to set it, or load it from a file,
etc.
> 
> Why make things more complex by introducing more and more layers of stuff?
> 

This would satisfy the proponents of the strict declarative approach.  I agree,
probably not essential.  It would allow you to not have to worry about the
ordering of certain "global init" properties, but, not essential, I agree.

> > 4. In any case, need the ability to allow a property to be dynamically
> > resolved,
> >   in the event it contains "bla_bla_${prop}".  Could have a task to do this:
> >   <resolve-property>.   Of course, this could only be done on resettable
> >   properties, i.e. properties defined with <user-property>.
> 
> Or, as the case is in the documents that I've worked on to date, all
> property sub strings (strings of form ${propname}) are evaluated right at
> Task execution time as they are being reflected into the TaskAction.
> 
> It's clean, simple, straightforward. It's all we need.
> 

amen, again....




Mime
View raw message