Summary: | Append property prefix to entries in property file values | ||
---|---|---|---|
Product: | Ant | Reporter: | Remie Bolte <remie> |
Component: | Core tasks | Assignee: | Ant Notifications List <notifications> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | ||
Priority: | P2 | ||
Version: | 1.7.1 | ||
Target Milestone: | 1.8.2 | ||
Hardware: | PC | ||
OS: | Windows XP |
Description
Remie Bolte
2008-10-29 01:57:29 UTC
just offering another workaround: use loadproperties instead of the property task and implement your manipulations as a filter(chain). Personally this seems to violate the principle of least surprise. I would think one would expect "internal" substitutions to work properly independently of prefix decoration. At the same time, when we get this fixed I would expect the change to fall into the "possibly breaking changes" section of WHATSNEW. I agree that there is a conceptual problem with replacing nested properties. I would see it as an added feature instead of default behavior. The suggested workaround of loadproperties with a filterchain would actually work for me. I'm fine with having a default "property" task with the least surprise and a more advanced "loadproperties" that allows manipulation. However, the workaround of using the loadproperties with a filterchain / replacetokens currently doesn't seem to work for me. The prefixlines works fine, but the replace either doesn't take place, or it takes place after the properties have been resolved and registered (either way not working). I'm using ant 1.7.0 to test the loadproperties workaround, I will try it with 1.7.1 tomorrow. it looks like this has been fixed in ant 1.8.2 by the introduction of the prefixValues attributes Yes, Owen, you are correct. |