cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: Building changes into the top level sitemap
Date Tue, 05 Dec 2006 16:50:19 GMT

On 5 Dec 2006, at 14:04, Daniel Fagerstrom wrote:

> 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.

Good :)

>> 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 
> 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 ;)

Documentation would really help.

I have just been working on an established project that is built from  
2.2 and I could see the advantages of the new platform.

However, many perceive 2.2 as almost unusable. It clearly is being  
used but the procedures are very different from 2.1 ..... the results  
can be completely unpredictable ..... it will compile one minute and  
not the next, this is very off-putting. If the less experienced  
developers like myself cannot feel confidant with the build system  
for 2.2 what hope do we have of users embracing it?

Sorry this is in no way intended as a personal criticism, merely a  
statement of facts as I perceive them.

 From my PoV, the areas most urgently in need of documentation are :

A cookbook for how to develop 2.2 (as you describe)
Recipes for starting your own project.
Troubleshooting hint for solving common build problems.

Reading the Maven2 manual as Giacomo suggested, may well help :) but  
that still leaves understanding how 2.2 performs it's built using Maven.

Thanks for your reply :)

regards Jeremy

View raw message