ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Rosenberg" <>
Subject Re: Property substitutions, Contributed Tasks, & New features
Date Mon, 08 Jan 2001 19:33:32 GMT
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.

2. run-time evaluated, resettable.
    This is the current 'userProperty', which is not accessible via the Ant XML build file,
    but which is accessible via scripting:  currProject.setUserProperty("test.prop","test.value");
    It seems to me this should be allowed in the XML syntax.  Why not allow it to be set
    with a <user-property> task, possibly overwriting a previously set value, etc.?

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.

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>.


----- Original Message ----- 
From: "James Bucanek" <>
To: <>
Sent: Monday, January 08, 2001 12:04 PM
Subject: Property substitutions, Contributed Tasks, & New features

> Greetings,
> Does anyone know where I can find:
> (a) A place to find or post contributed Ant Tasks?
> (b) A place to find out what new features are being added, or 
> considered, for the next version of Ant?
> I ask because I've been somewhat annoyed that Project.getProperty() 
> doesn't perform substitutions ("bla bla ${prop}").  It's up to the 
> code that sets the property to make the substitution before setting 
> the value.
> This makes it impossible to make forward references in property 
> values because the property substitution has to be preformed prior to 
> setting the value.  Nor can the substitution value be modified at 
> run-time.
> To resolve this in the short term, I wrote a ResolveProperties Task 
> that rattles through the Project's properties and fixed up all of the 
> references.  So, coming back to (a), it would seem likely that 
> someone else might want something like this and I'd like to made that 
> available to the Ant community in general.
> On a side note, my code also resolves substitutions in the property's 
> name as well.  This lets me get around the limitation of the 'if=' 
> clause of targets that only test to see if a property has been 
> defined, not it's value (true or false).  I can now create two 
> properties:
>      needsManifest=true
>      needsManifest-${needsManifest}=whatever
> When ResolveProperties is finished, I'll have two properties defined: 
> needsManifest=true and needsManifest-true=whatever.  Now I can 
> happily write <target name="buildManifest" if="needsManifest-true">...
> Getting back to (b), I would strongly suggest that 
> Project.getProperty() (or Project.getResolvedProperty(...)) be 
> modified to perform the property value substitution on the fly. 
> About the only thing you'd need to do is put a cap on the iteration 
> depth to catch circular substitutions.
> So, how does one go about suggesting such a change?  And, more 
> importantly, how do you find out if a such a change has already been 
> proposed or implemented?
> Thanks,
> James
> __________________________________
> James Bucanek
> <>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message