Carsten Ziegeler wrote:
Geoff HowardAFAICS, this should work. The only place where we would need these filters is when we're working with non-XML files.
Knowing that properties are already replaced, do you see a purpose for this still?
Yes, filtering :) Just use a @loglevel@ in a patch file for the logging configuration, and without the patch it doesn't work.
Now, if I understand it correctly now (I have to sort out the
difference between filtering and properties), this only affects
the following values:
<filter token="Name" value="${fullname}"/>
<filter token="name" value="${fullname}"/>
<filter token="year" value="${year}"/>
<filter token="version" value="${version}"/>
<filter token="date" value="${TODAY}"/>
<filter token="released.version" value="${released.version}"/>
<filter token="loglevel" value="${build.webapp.loglevel}"/>
The only really meaningful is loglevel.
Do I understand you correctly that if I would write
${build.webapp.loglevel} in my patch file instead @loglevel@, it would
work? If so, we could simply add a loglevel property with the
value from ${build.webapp.loglevel} and switch from @loglevel@
to ${loglevel} and remove my changes. That would be great and we
all are happy then :)
Exactly. Although I didn't quite understand the bit about adding a loglevel property for build.webapp.loglevel - it already is a property isn't it? And that's the benefit of property expansion over filtering -- you don't have to define the filter tokens and can therefore work with arbitrary properties (even ad hoc user defined ones).
Geoff
