You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by cz...@apache.org on 2004/03/15 19:11:25 UTC
cvs commit: cocoon-2.1/tools/targets webapp-build.xml
cziegeler 2004/03/15 10:11:25
Modified: . status.xml
tools/targets webapp-build.xml
Log:
<action dev="CZ" type="fix" fixes-bug="27217" due-to="Andreas Hartmann" due-to-email="andreas@apache.org">
Build System: Apply filtering to patched configurations coming from the different blocks (loglevel etc.)
</action>
Revision Changes Path
1.281 +4 -1 cocoon-2.1/status.xml
Index: status.xml
===================================================================
RCS file: /home/cvs/cocoon-2.1/status.xml,v
retrieving revision 1.280
retrieving revision 1.281
diff -u -r1.280 -r1.281
--- status.xml 15 Mar 2004 11:38:23 -0000 1.280
+++ status.xml 15 Mar 2004 18:11:24 -0000 1.281
@@ -212,6 +212,9 @@
<changes>
<release version="@version@" date="@date@">
+ <action dev="CZ" type="fix" fixes-bug="27217" due-to="Andreas Hartmann" due-to-email="andreas@apache.org">
+ Build System: Apply filtering to patched configurations coming from the different blocks (loglevel etc.)
+ </action>
<action dev="CZ" type="fix" fixes-bug="27518" due-to="Michal Durdina" due-to-email="durdina@asset.sk">
Portal: Fix problems with minimizing/maximizing of portlets.
</action>
1.10 +13 -0 cocoon-2.1/tools/targets/webapp-build.xml
Index: webapp-build.xml
===================================================================
RCS file: /home/cvs/cocoon-2.1/tools/targets/webapp-build.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- webapp-build.xml 8 Mar 2004 06:07:15 -0000 1.9
+++ webapp-build.xml 15 Mar 2004 18:11:25 -0000 1.10
@@ -153,6 +153,19 @@
</target>
<target name="webapp" depends="prepare-webapp,prepare-webapp-samples,prepare-webapp-docs,prepare-webapp-javadocs,prepare-webapp-deprecated,validate-jars,validate-config,custom-conf" description="Builds web application folder">
+ <!-- Filter the patched files again to eventually apply filtering to patched blocks -->
+ <copy file="${build.webapp}/sitemap.xmap"
+ tofile="${build.webapp}/sitemap.xmap"
+ overwrite="true" filtering="on"/>
+ <copy file="${build.webapp}/WEB-INF/cocoon.xconf"
+ tofile="${build.webapp}/WEB-INF/cocoon.xconf"
+ overwrite="true" filtering="on"/>
+ <copy file="${build.webapp}/WEB-INF/logkit.xconf"
+ tofile="${build.webapp}/WEB-INF/logkit.xconf"
+ overwrite="true" filtering="on"/>
+ <copy file="${build.webapp}/WEB-INF/web.xml"
+ tofile="${build.webapp}/WEB-INF/web.xml"
+ overwrite="true" filtering="on"/>
</target>
<target name="war" depends="webapp" description="Builds web application archive">
Re: cvs commit: cocoon-2.1/tools/targets webapp-build.xml
Posted by Geoff Howard <co...@leverageweb.com>.
Carsten Ziegeler wrote:
>Geoff Howard wrote:
>
>
>
>>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?
>>
>>
>Yes, but with a long and not so intuitiv name. That's why I
>suggested the shorter form.
>
>
Ah, I see.
>>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).
>>
>>
>Yes, absolutely. Sorry for the confusion, I will correct this right
>now.
>
>
No, no problem - this was obviously a pretty hidden feature! I'll make
a better note on the wiki. I don't remember who actually implemented it
(I think it was Unico?) but someone may want to check my wiki edits to
make sure they're accurate.
Geoff
RE: cvs commit: cocoon-2.1/tools/targets webapp-build.xml
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Geoff Howard wrote:
>
> 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?
Yes, but with a long and not so intuitiv name. That's why I
suggested the shorter form.
> 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).
Yes, absolutely. Sorry for the confusion, I will correct this right
now.
Carsten
Re: cvs commit: cocoon-2.1/tools/targets webapp-build.xml
Posted by Geoff Howard <co...@leverageweb.com>.
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).
Geoff
Re: cvs commit: cocoon-2.1/tools/targets webapp-build.xml
Posted by Upayavira <uv...@upaya.co.uk>.
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.
Upayavira
RE: cvs commit: cocoon-2.1/tools/targets webapp-build.xml
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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 :)
Carsten
Re: cvs commit: cocoon-2.1/tools/targets webapp-build.xml
Posted by Geoff Howard <co...@leverageweb.com>.
Carsten Ziegeler wrote:
>Joerg Heinicke wrote:
>
>
>>Geoff Howard wrote:
>>
>>
>>
>>>> Modified: . status.xml
>>>> tools/targets webapp-build.xml
>>>> Log:
>>>> <action dev="CZ" type="fix" fixes-bug="27217" due-to="Andreas
>>>>Hartmann" due-to-email="andreas@apache.org">
>>>> Build System: Apply filtering to patched
>>>>
>>>>
>>configurations coming
>>
>>
>>>>from the different blocks (loglevel etc.)
>>>> </action>
>>>>
>>>>
>>>Was this necessary? We already have property substitution
>>>
>>>
>>working -
>>
>>
>>>is filtering also necessary? It seems to create extra
>>>
>>>
>>overhead (all
>>
>>
>>>those new copies).
>>>
>>>
>Ok, this feature has been requested by users (bug 27217) and if you
>use properties in the configuration of the blocks (like loglevel,
>see below) then these values are not replaced which is imho very
>bad. So I fixed this and yes this requires copying/filtering four
>files which might add another second to the ten minutes build time :)
>
>
Properties are replaced - check out
src/blocks/slide/conf/slide-target.xlog for example: it uses
${context-root}. I think either the bug author did not realize this
feature exists, or when the feature was added (a few months ago?) we did
not know the bug existed.
On the copying - I didn't look carefully and assumed the filtering
happened to each patch file, not the final targets. Still, these seem
like completely overlapping (and therefore confusing) features - am I
misunderstanding?
Now, I thought this property expansion was added to the wiki docs about
xpatch but can't now find it. Once we decide what to do about this I'll
make sure to fix them.
>Anyway, if you (or someone else) thinks that this isn't necessary
>then I can revert it and we will close the bug with "wontfix".
>
>
Knowing that properties are already replaced, do you see a purpose for
this still?
Geoff
RE: cvs commit: cocoon-2.1/tools/targets webapp-build.xml
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Joerg Heinicke wrote:
>
> Geoff Howard wrote:
>
> >> Modified: . status.xml
> >> tools/targets webapp-build.xml
> >> Log:
> >> <action dev="CZ" type="fix" fixes-bug="27217" due-to="Andreas
> >> Hartmann" due-to-email="andreas@apache.org">
> >> Build System: Apply filtering to patched
> configurations coming
> >> from the different blocks (loglevel etc.)
> >> </action>
> >
> >
> > Was this necessary? We already have property substitution
> working -
> > is filtering also necessary? It seems to create extra
> overhead (all
> > those new copies).
Ok, this feature has been requested by users (bug 27217) and if you
use properties in the configuration of the blocks (like loglevel,
see below) then these values are not replaced which is imho very
bad. So I fixed this and yes this requires copying/filtering four
files which might add another second to the ten minutes build time :)
Anyway, if you (or someone else) thinks that this isn't necessary
then I can revert it and we will close the bug with "wontfix".
>
> Even worse, it does not work. Tried it with the
> forms-category.xlog in the form block and set the
> @log-level="@loglevel@". Came out in logkit.xconf unreplaced.
>
Hmm. It did work when I tested it yesterday at home, but here on my
laptop it doesn't work. Interesting. Anyway, I just changed it and
now it works.
Carsten
Re: cvs commit: cocoon-2.1/tools/targets webapp-build.xml
Posted by Joerg Heinicke <jo...@gmx.de>.
On 15.03.2004 19:48, Geoff Howard wrote:
>> Modified: . status.xml
>> tools/targets webapp-build.xml
>> Log:
>> <action dev="CZ" type="fix" fixes-bug="27217" due-to="Andreas
>> Hartmann" due-to-email="andreas@apache.org">
>> Build System: Apply filtering to patched configurations coming
>> from the different blocks (loglevel etc.)
>> </action>
>
>
> Was this necessary? We already have property substitution working - is
> filtering also necessary? It seems to create extra overhead (all those
> new copies).
Even worse, it does not work. Tried it with the forms-category.xlog in
the form block and set the @log-level="@loglevel@". Came out in
logkit.xconf unreplaced.
Joerg
Re: cvs commit: cocoon-2.1/tools/targets webapp-build.xml
Posted by Geoff Howard <co...@leverageweb.com>.
cziegeler@apache.org wrote:
> cziegeler 2004/03/15 10:11:25
>
> Modified: . status.xml
> tools/targets webapp-build.xml
> Log:
> <action dev="CZ" type="fix" fixes-bug="27217" due-to="Andreas Hartmann" due-to-email="andreas@apache.org">
>
> Build System: Apply filtering to patched configurations coming from the different blocks (loglevel etc.)
>
> </action>
Was this necessary? We already have property substitution working - is
filtering also necessary? It seems to create extra overhead (all those
new copies).
Geoff