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]