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
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116326232408386&w=2).
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 ;)
/Daniel
