Re: Handling configuration files during cocoon update
Sorry if I misunderstood - the previous post suggested that it was good practice to integrate your changes as part of the build process, rather than making them manually - and directly - to the files after building Cocoon. I was not talking about the use case for a *single* project, but the case for multiple projects, all as part of one Cocoon deployment, that now needed to be upgraded - not as a result of project changes but because of wanting to a use a newer version of Cocoon. [EMAIL PROTECTED] 2005/11/28 08:53:47 AM You only need to rebuild Cocoon if you have integrated your product into its build. If you use the process described at http://wiki.apache.org/cocoon/HowToBuildAndDeployCocoonWithMaven?highlight=%28maven%29 then you only need to rebuild Cocoon when you want to upgrade it. To integrate changes to your project you must rebuild and redploy your project. Ralph Derek Hohls wrote: 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? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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 http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html 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 [EMAIL PROTECTED] 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling configuration files during cocoon update
Derek Hohls wrote: Sorry if I misunderstood - the previous post suggested that it was good practice to integrate your changes as part of the build process, rather than making them manually - and directly - to the files after building Cocoon. There are two schools of thought. Some folks like to create their project as a block and then get cocoon's build process to build it. I find that tedious when migrating from one Cocoon release to the next. However, even the process I suggested does not have any manual changes. I was not talking about the use case for a *single* project, but the case for multiple projects, all as part of one Cocoon deployment, that now needed to be upgraded - not as a result of project changes but because of wanting to a use a newer version of Cocoon. We handle that by doing that only as part of a product upgrade. Then it is just a matter of changing the Cocoon dependency and making any adjustments required due to release changes. If you integrate your build into Cocoon's then IMO upgrading Cocoon becomes a lot more painful. However, I want to emphasize that this does not necessarily apply to the upcoming 2.2 releases. As I understand things, in 2.2 your project will become one or more blocks (maven projects) which will include Cocoon blocks and/or the core as dependencies. In that case, you would have to create a new release of your project with changes to the Cocoon dependencies. You would then rebuild your project and redeploy. Ralph Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling configuration files during cocoon update
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.
Re: Handling configuration files during cocoon update
You only need to rebuild Cocoon if you have integrated your product into its build. If you use the process described at http://wiki.apache.org/cocoon/HowToBuildAndDeployCocoonWithMaven?highlight=%28maven%29 then you only need to rebuild Cocoon when you want to upgrade it. To integrate changes to your project you must rebuild and redploy your project. Ralph Derek Hohls wrote: 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? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling configuration files during cocoon update
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 smime.p7s Description: S/MIME cryptographic signature
Re: Handling configuration files during cocoon update
On Saturday 26 November 2005 02:41 pm, Bertrand Delacretaz wrote: 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. ... Thanks for pointing me in the right direction , Bertrand! Sincerely, Shawn C. Powell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling configuration files during cocoon update
This is probably a good time to point out one of the features of 2.2. You no longer need to use XConfToolTask. Instead, you can place your xconf files into a directory where they are automatically included. Also, you can place the component section of the sitemap in an xconf file and include it into your sitemap leaving only the pipelines in the sitemap (see the main sitemap.xmap for an example). Ralph Shawn C. Powell wrote: On Saturday 26 November 2005 02:41 pm, Bertrand Delacretaz wrote: 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. ... Thanks for pointing me in the right direction , Bertrand! Sincerely, Shawn C. Powell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
