cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: cvs commit: cocoon-2.1/tools/targets webapp-build.xml
Date Tue, 16 Mar 2004 12:37:44 GMT
Upayavira wrote:

> Carsten Ziegeler wrote:
>> Geoff Howard
>>> 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 :)
> AFAICS, this should work. The only place where we would need these 
> filters is when we're working with non-XML files.

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).


View raw message