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]