On 20 Nov 2003, at 09:59, Upayavira wrote:
Jeremy Quinn wrote:
On 19 Nov 2003, at 18:37, Upayavira wrote:
Jeremy,
Splendid article. Stuff I've been thinking about a lot recently too.
Just one useful quote from the Ant manual:
<property environment="env"/> <echo message="Number of Processors = ${env.NUMBER_OF_PROCESSORS}"/> <echo message="ANT_HOME is set to = ${env.ANT_HOME}"/>
With this, you can get at ${env.COCOON_HOME}, etc.
Thanks Upayavira
Did you read the bit earlier about the scheme having a flaw because of no variable substitution in the <xmap> tag's attributes?
No I didn't.
How difficult would it be to add this?
Coding-wise, pretty trivial, just wrap each string with getProject().replaceProperties().
cool
Before we do this, I think we should sort out a few details, following on from a comment from Vadim.
OK
Do we want to automatically replace properties, and remove the replace-properties attribute? Are there any situations in which this could cause a problem?
Not that I can think of
Similarly, are there any situations in which it could cause a problem in the top level attributes, e.g. xpath, or include-before?
Again, I cannot think of any
We could:
(1) Remove the replace-properties attribute, and replace properties automatically in the content, and in the top level attributes.
(2) Leave the replace-properties attribute, and only replace properties in the top level attributes if it is set to true.
There are other options, but these two make the most sense. What do people think?
I personally go for option 1.
Who is going to need a string like "${variable.name}" as *data* in their patch files?
It does not resemble anything in a normal sitemap etc.
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
