cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Refondini <patrick.refond...@pobox.com>
Subject Re: Building changes into the top level sitemap
Date Tue, 05 Dec 2006 22:31:51 GMT
Jeremy Quinn wrote:
> 
> 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.
> 
> 
> OK
> 
>> 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 ;)
> 
> 
> 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.
I am trying to learn and compile information in that direction (Recipes).

e.g. in "How to run block built with cocoon-22-archetype-block" thread 
Reinhard suggested me a "Getting started in 5 minutes document that 
explains how to connect to another block and how to use inheritance" 
would be welcome.

I am not there yet but I am very willing to archieve that in the near 
future.

So please bear with my user stupid questions to come :)

Looking forward to test the AJAX upload widget !

Patrick

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


Mime
View raw message