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 >