cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Building changes into the top level sitemap
Date Tue, 05 Dec 2006 14:04:19 GMT
Jeremy Quinn skrev:
> Hi Guys
> I am trying to get support for the new Upload Progress Bar working in 
> Cocoon 2.2.
> I need to add a new system pipeline to the top-level sitemap, like 
> (and adjacent to) the one that handles :
>     <map:match pattern="_cocoon/resources/*/**">
> this is the snippet :
>     <map:match pattern="_cocoon/system/*/**">
>       <map:select type="resource-exists">
>         <map:when test="system/{1}/sitemap.xmap">
>           <map:mount src="system/{1}/sitemap.xmap" 
> uri-prefix="_cocoon/system/"/>
>         </map:when>
>         <map:otherwise>
>           <map:mount 
> src="resource://org/apache/cocoon/{1}/system/sitemap.xmap" 
> uri-prefix="_cocoon/system/{1}/"/>
>         </map:otherwise>
>       </map:select>
>     </map:match>
> The purpose is to mount Block-Level system pipelines.
> I /think/ the place I make this change is in :
>     /core/cocoon-webapp/src/main/webapp/sitemap.xmap
> (But TBH I am not sure)

Yes, that should be the place.

> Next I am trying to get this compiled in, so that it is available for 
> the 'cocoon-dist-samples' and everything else that may be built from 
> this distribution.
> I have tried to compile this in, but it never becomes available to the 
> samples.
> I tried running $ mvn package in both :
>     core/cocoon-webapp/
>     dists/cocoon-dist-samples/
> Neither results in the changes happening to the file at :
>     dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
> TBH I find this new build system so deeply opaque, I do not know where 
> to start solving this.
> What am I supposed to do ?

First, the dist samples (cocoon-dist-samples, cocoon-dist-publishing) 
are really just distribution samples. They just unpack and package 
together the cocoon-webapp and samples and implementations from the 
various blocks. For development of samples it would be really 
inconvenient to work from the dist samples as you would need to rebuild 
about the whole trunk after each change.

So what I would recommend to do is to start from the cocoon-webapp 
instead and to add (locally) all the block samples you need for your 
work, as dependencies to cocoon-webapp. What happens then is that during 
startup Cocoon will find all the COB-INF directories from the block 
samples from the class path. From here two different things can happen: 
if the block is in a jar at the class path, the COB-INF directory of the 
block will be unpacked in a blocks/<blockname> directory in the temp 
directory of the servlet container. If the block is in a class directory 
(if you devolop in Eclipse e.g. and your cocoon-webapp depends on 
another block project), Cocoon will read directly from the block without 
any unpacking.

All this is done by using a new blockcontext protocol that is aware of 
the locations of the blocks (see

So the above should hopefully make it easier to work on making the new 
stuff functional. After that you can try to compile the dist samples and 
see if it works in them as well.

The above described functionality actually make it easier and faster 
than ever to develop samples, as you can test them without any copying 
or jetty restarts at all in Eclipse. But some documentation about this 
would probably not hurt ;)


View raw message