Return-Path: 
 <cocoon-dev-return-42586-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 82339 invoked by uid 500); 21 May 2003 17:41:03 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 82323 invoked from network); 21 May 2003 17:41:02 -0000
Received: from smtp1.xs4all.be (195.144.64.135)
  by daedalus.apache.org with SMTP; 21 May 2003 17:41:02 -0000
Received: from outerthought.org (stat88-18.adsl.xs4all.be [195.144.88.18])
	by smtp1.xs4all.be (8.12.9/8.12.9) with ESMTP id h4LHf41A023543
	for <cocoon-dev@xml.apache.org>; Wed, 21 May 2003 19:41:05 +0200
Message-ID: <3ECBBA2F.5000309@outerthought.org>
Date: Wed, 21 May 2003 19:41:03 +0200
From: Marc Portier <mpo@outerthought.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en, nl-be
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: deploying and updating a cocoon site
References: <1053477567.29101.23.camel@car.pixar.com>
	 <baf4hl$46v$2@main.gmane.org> <1053531787.22787.3.camel@car.pixar.com>
In-Reply-To: <1053531787.22787.3.camel@car.pixar.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N



Miles Egan wrote:
> On Tue, 2003-05-20 at 23:00, Stefano Mazzocchi wrote:
> 
>>on 5/20/03 7:39 PM Miles Egan wrote:
>>
>>
>>>Right now deploying and updating a cocoon site with new cocoon builds is
>>>fairly painful.  I have to directly edit the cocoon.xconf to toggle
>>>check-reload for the sitemap and edit the top-level sitemap to mount my
>>>sitemap.  It would be great if there were a way to do this without
>>>having to mangle the distributed versions of these files.  Is there any
>>>way to do this that I'm missing?
>>
>>No, since we are aiming for big changes in this realm, we decided to
>>release cocoon 2.1 and attack that problem right after.
>>
>>We are aware of the lack of usability of cocoon from that side and being
>>*myself* terribly annoyed by it, I can't wait until we do release 2.1 to
>>start doing something about it.
>>
>>This is all I can tell you right now.
> 
> 
> Thanks to everybody that replied.  I think for now I'm just going to
> maintain separate copies of cocoon.xconf and the sitemap and clobber the
> cocoon copy when I start it up.  It means manually merging new stuff in
> from these files when they change in cvs, but I can live with that for
> now.
> 
> It would also be pretty helpful if I could refer to global system
> properties in either file.  It would help a lot if I could "ant run
> -Dcocoon.check-reload=false" or something like that and refer to this
> parameter in the xconf or sitemap files.  I couldn't figure out a way to
> do this now (except maybe a custom input module for the sitemap).  Is
> there a way?
> 

ant hack way would be to introduce it during build
you could use copy with @tokens@ that get replaced

or if it would be a smaller xml file to generate you could 
consider using the
<echo file="filename-to-make.xml"><[CDATA[<?xml ....

in here the use of ${cocoon.check-reload} will be replaced

]]></echo>


not sharp enough on the inputmodules to help there, check-reload 
looks to me however as something outside the input-module realm, 
but I could be mistaken

HTH

> miles
> 

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org