cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Huttar <lars_hut...@sil.org>
Subject Re: deploying to separate environments using different database servers
Date Thu, 23 Jun 2005 14:54:05 GMT
Mark Lundquist wrote:

>
> Hi Lars,
>
> On Jun 21, 2005, at 3:13 PM, Lars Huttar wrote:
>
>> Dear Cocoon-based webapp developers,
>>
>> I would be interested to hear how others have handled this issue.
>>
>> You have Cocoon applications whose source code is stored in a 
>> repository. You want to be able to install them on multiple 
>> development machines (on each developer's desktop), on test servers, 
>> and on production servers.
>> The environments (dev, test, production) use separate database 
>> servers as well as separate web servers.
>> But when you checkout the source code from the repository onto 
>> various web servers, they're all pointing to the same database 
>> server, because they all have the same datasources defined in 
>> cocoon.xconf.
>>
>> You could then go in and modify cocoon.xconf separately for each 
>> environment, but that could get to be a lot of time-consuming and 
>> error-prone work. (We currently have 38 datasources defined for all 
>> our applications! Maybe not all of them are still used, but most are, 
>> I believe.)
>> How do you automate this task?
>
>
> With the xpatch Ant task, included with Cocoon (the cocoon build uses 
> it). See http://wiki.apache.org/cocoon/XPatchTaskUsage.
>
Thanks for the suggestion.
It's good to know about xpatch.

Presumably in our situation, we would set up our source control system 
to run xpatch whenever certain files are updated from source control.

I'm hesistant to use something like that, for two reasons.
One is that it adds extra steps to our process. Up till now, developers 
on our team have not had to know anything about Ant.
The other is that if xpatch modifies a file on update, source control 
will flag it as "modified" when there is nothing that needs to be 
committed to the repository. This will confuse developers and make it 
more difficult for them to tell when a file really does need to be 
committed.
Maybe you have some way to deal with that?

I think our solution will be to use parameter entities and external 
entities, if I can get it to work.

Lars



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message