Does this imply that if you have incremental changes to these
files (more projects being added to an *existing* Cocoon
installations) over time, that you should be rebuilding and
redeploying Cocoon each time?

>>> [EMAIL PROTECTED] 2005/11/26 10:41 PM >>>
Le 26 nov. 05, à 20:56, Shawn C. Powell a écrit :

> ...How does one preserve/handle/integrate-changes to the toplevel
> runtime
> configuration files such as xconf and web.xml during an update for
> instance
> from 2.1.7 to 2.1.8?...

The best way to handle this is to avoid modifying these files directly,
and use our XConfToolTask with ant to patch these files at build time.
The source code of that task (tools/src/anttasks/XConfToolTask.java)
includes some explanations.

There are many examples of such *.xconf (to patch cocoon.xconf) and
*.xweb (to patch web.xml) files in the blocks source code under
src/blocks.

If you'd like to have an example that you can use in your build, the
bricks-cms example application [1] uses this mechanism as well, all the
files found under src/cocoon/xconf are processed with the XConfToolTask
to patch the configs.

By the way: the build system used by bricks-cms is a nice way of
creating an app that is fairly independent from the Cocoon code base,
and can move relatively easily between releases.

-Bertrand


[1] http://wiki.apache.org/cocoon/BricksCms

--
This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice.
Views expressed herein do not necessarily represent the views of the CSIR.

CSIR E-mail Legal Notice

CSIR Copyright, Terms and Conditions

For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice
send a blank message with "REQUEST LEGAL" in the subject line to CSIR HelpDesk


This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.