Would it be as simple as calling PropertyHelper.replaceProperties(…) at line 
1143 in Main with the “targetDescription” string?

Thanks,
~Roger


> On Jul 20, 2022, at 12:46 AM, Stefan Bodewig <bode...@apache.org> wrote:
> 
> On 2022-07-19, Roger Whitcomb wrote:
> 
>> I have a target description that has “${result.jar}” embedded
>> within. But “ant -p” doesn’t do the substitution. I’m presuming that’s
>> because the “-p” processing doesn’t evaluate condition or property
>> tasks. But, should it? Would that be a huge code change?
> 
> Actually, properties are not expanded for any of the target attributes
> at all. Well, if and unless are an exception in a way as properties are
> expanded when the attributes are evaluated.
> 
> Properties get their value at runtime while executing tasks. Targets are
> part of the static structure which is set up and configured before most
> tasks are run. name, description and depends are not expected to change
> at runtime so we never thought about making them dynamic in the sense
> that their value may change after parsing the build file. For depends
> this really would make things quite a bit more complex as the graph of
> targets to execute then would change while it is being executed. name is
> in the same category as it is what is used in depends.
> 
> It might be possible to expand properties for the description but that
> would see the value of a property at the point in time when the build
> file has been parsed, and maybe after all top-level tasks (those outside
> of any target) have been executed. But given that expanding properties
> for any of the other target attributes posed problems we never
> implemented that.
> 
> There even is https://bz.apache.org/bugzilla/show_bug.cgi?id=38915 -
> just sixteen years old :-). The report properly states we do execute top
> level tasks before printing the project help, so the properties set
> there would be available. And Peter has been right when he said
> executing the top-level tasks during the parse phase would be "not
> good", but we had to keep that for backwards compatibility reasons.
> 
> Stefan
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> For additional commands, e-mail: user-h...@ant.apache.org
> 

Reply via email to