Page: http://wiki.cocoondev.org/Wiki.jsp?page=YourCocoonBasedProject , version:
3 on Fri May 30 20:02:21 2003 by MarcPortier
+ * modification of existing XML config files for Cocoon
- The more painful part is the needed modification of existing XML config files
for Cocoon.
+ This last thing is what is the biggest issue for most of us. However,
stealing from how the blocks inside cocoon are working we can achieve this
through the use of the new xpatch task. (Inside Cocoon distro)
- ... todo add some explanation of the elements in the target to do so:
+ This piece of ant build.xml does the trick:
- ... todo add/explain simple xpatch file
-
+ In combination with the xconf-patch-file in the ${src.cocoon} directory.
+ A very classical example of such file would be:
+ | Just an example section that will be slided into the cocoon.xconf
- | Declares the AppleInstanceManager to use.
- | This piece of configuration is automatically inserted
- | in the cocoon.xconf
- +-->
? ^
+ +-->
? ^^
+ For more advanced usage of this patching mechanism there is a separate Wiki
page foreseen: [XPatchTaskUsage]
+
+ ----
+ !Addendum
+
+ Some people have asked how to do the patching based on values of system
properties, haven't really tried this myself but you might consider creating
your xconf files on the fly with a trick like this
+
+ {{{
+ <target name="make-xpatchfile">
+ <echo file="myfile.xconf"><![CDATA[<?xml version="1.0"?>
+ ....
+
+ <component class="${component-classname}" ..
+
+ ....
+
+ ]]></echo>
+ </target>
+ }}}
+
+ in which case you could call ant with some
{-Dcomponent-classname=package.subpackage.MyClass}
- ... todo refer to XPATCH page
- ... todo add the extension-trick of using the <echo> to create your xconf
file dynamically
- (and based on -Dyour-properties=...)
-
-
Page: http://wiki.cocoondev.org/Wiki.jsp?page=InputModules , version: 15 on Fri
May 30 20:57:31 2003 by BenjaminYoung
+ ----
