----- Original Message -----
From: "James Duncan Davidson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]> 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....
