cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: deploying and updating a cocoon site
Date Wed, 21 May 2003 12:27:28 GMT

Miles Egan wrote:
> Thanks.  Nice to know people are thinking about it at least.

me too,

this is what I use currently (warning: a hack) to ease the pain 
until post-2.1-nirvana (would even need some additional hacking 
to work on 2.0.x)

somewhere I have some (possibly more then one)
source distribution of cocoon lingering

+ cocoon-cvs-head
   +- the known subdir structure

+ cocoon-2.1-milestone-release-whatnot
   +- the known subdir structure

and then there is the project-specific stuff I'm working on

+ myproject
   +- lib
        ! not containing the cocoon jars,
        ! since that depends on the distribution used
   +- src
      +- java
      +- etc
         +- cocoon
           +- my-extension.xconf:
                ! xpatch-task syntax to augment the cocoon.xconf
           +- mount-subdir
              +- sitemap.xmap
          ! specifies cocoon-dist.home of distribution to use
   +- build.xml

where there is also some convenience scripts:

   +- getcocoon.bat
          ! uses the cocoon build.bat in the distribution
          ! of choice (see cocoon-dist.home)
          ! to build cocoon over to ./tools/cocoon/webapps
          ! and also to compile the xpatch-task code towards
          ! ./tools/cocoon/taskdefs
   +- runcocoon.bat
          ! uses the cocoon.bat in the distribution
          ! of choice (see cocoon-dist.home)
          ! to launch jetty for testing with the
          ! webapp at ./tools/cocoon/webapps

and the mentioned 'build' environments

   +- tools
     +- cocoon
       +- taskdefs
       +- webapp
   +- build

what goes about is controlled by the ant build file that declares 
  the following
- classic init target
- classic compile target

- get_cocoon and run_cocoon tasks that guard dependecies, sets 
env variables but just wraps around the mentioned convenience scrips

- test_cocoon target to check if tools/cocoon is containing the 
stuff you'ld expect
- webapp task that
   1. taskdefs xpatch and uses it to
   2. patch the tools/cocoon/webapp automatically
   3. copy over the content/config stuff
      from src/etc/cocoon to tools/cocoon/webapp

- deploy task to push it over to your webcontainer of choice

dunno if this makes sense, it's probably just me being to lazy 
and incapable of remembring all the steps I need to do manually 
(to be more generally applicable the *.bat should get 
strengthened with some *.sh versions, haven't come to it, but 
frankly I don't even know if this is actually addressing a more 
common need)

Looking into the trouble you face, we might still need to provide 
some patches for the xpatch task as Bertrand and Giacommo are 
getting to... (haven't studied its full powers yet)

to get some thoughts going this is a sample xconf-augmenting 
file: (inserting an element)

<xconf xpath="/cocoon" 

   <!-- This piece automatically inserted in the cocoon.xconf -->
       logger="" />

haven't seen a way to do the deletions Giacommo is referring to, 
and need some time in the code to check if updates are foreseen

I guess, the full spectrum is covered by
(insert, update, delete) * (elements, attributes)

hm, getting lengthy again, maybe something to wikify after all if 
we could easily fit the wholes in this story (and even if it will 
not be needed after the full block thing is there)


> On Tue, 2003-05-20 at 20:15, Geoff Howard wrote:
>>I'm working on something to help with this right now.  In the end, I picture
>>either a new build target, or a customizable block.  Unfortunately, I've put
>>all of about 30 minutes in so far so I don't have much to show for myself.
>>I don't know of anything that allows one to do what you're hoping for.
>>Geoff Howard
>>>-----Original Message-----
>>>From: Miles Egan []
>>>Sent: Tuesday, May 20, 2003 8:39 PM
>>>To: Cocoon Dev
>>>Subject: deploying and updating a cocoon site
>>>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?
>>>Miles Egan <>

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message