cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gavin Carothers <>
Subject Making a Block Run in Trunk, or Using Cocoon 2.2 Part II
Date Thu, 29 Jun 2006 15:11:04 GMT
Questions and Answers from Part I:

"looking in the docs"
refers to creating a block, but uses the cocoon-22-archetype-webapp
refers to a very strange archetype that happily no longer seems to exist 
SEEMS to be based on the "webapp" archetype.
refers to creating a block, and as it's under the block deployer this  
makes sense. The reason I ended up using the block archetype rather  
then webapp was simply that it seemed to be working.

Thursday, June 29th:

Based on messages from the mailing list, this morning begin with:

svn up
mvn install

Oops, org.apache.cocoon.template.jxtg.JXTemplateGeneratorTestCase and  
org.apache.cocoon.environment.FOMTestCase still fail.

mvn install -Dmaven.test.skip=true

Starting back were we ended yesterday. We have the archetype block  
created and want to see if the pipeline it deploys works.

mvn cocoon:deploy
mvn jetty6:run

Opening up Firefox and trying http://localhost:8888/toc-manager/ No  

No default type exists for 'map:pipeline' at file:/Users/gcarothers/ 

Okay, so some part of the configuration is likely screwed up. Lets go  
back to February when I last remember seeing this issue mentioned on  
the mailing list.

Ben Popes comment on adding dependencies causing the error gives us  
the best chance for fixing this quickly.

from the pom.xml, finding no blocks.xml or other place where  
dependencies are referenced in COB-INF we will try cleaning and  
deploying again.

mvn clean cocoon:deploy
mvn jetty6:run

Opening up Firefox and trying http://localhost:8888/toc-manager/ No  

No default type exists for 'map:pipeline' at file:/Users/gcarothers/ 

There is another <beans/> file in cocoon-core-applicationContext.xml  
lets see what removing it's license header does.


Okay, lets look into the issues from February a bit more deeply.  
dev&m=114089107113280&w=2 seems to mean that this got solved for  
cocoon-webapp, that's good. So lets take a look at that application  
since it works.

First thing we notice is this application has a META-INF directory  
which upon first inspection mentions spring, closer examination  
revels that this is used by OSGi and not the normal cocoon-block- 
deployer, so we can move on from here.

There seems to be a lot of stuff in here for the samples, being a  
demo application. We don't really want to deal with getting the  
samples to work at the moment we want to know why this webapp works  
and toc-manager doesn't. So going to remove the dependencies on the  
sample blocks. Simplify what we're building, and hope it still works.  
Upon removing those we find one other dependency left:


mvn clean cocoon:deploy jetty6:run

Well now, we have a running application without all the samples, in  
fact without much of anything. Excellent, lets see what's going on in  
the target/cocoon-webapp/ directory and compare that to our target/ 
toc-manager. Well, there we go. toc-manager's target webapp does not  
have a cocoon-core-sitemap.xmap, so no pipelines nor any of the other  
main components are every configured. In fact our block has no WEB- 
INF at all... hrm. Now clearly some of the items from COB-INF end up - 
in- the deployed WEB-INF but as I don't yet understand how that  
process works nor have I found documentation on it we are going to  
cheat. As this comes from the src/ directory and not from any  
dependency we will simply copy over the whole of WEB-INF into the  
src/ tree of toc-manager and see what happens.

cd toc-manager
mvn -o clean cocoon:deploy jetty6:run

Heh, as one might guess this did nothing. In fact none of the  
contents of WEB-INF was copied into target at all. Manually coping  
the cocoon-core-sitemap.xmap into target/ causes everything to work!  
We are running code!

minimac:~ gcarothers$ curl http://localhost:8888/toc-manager/
<?xml version="1.0" encoding="ISO-8859-1"?>
   <spring>This is a message coming from a Spring bean.</spring>

So, now how do we get cocoon-core-sitemap.xmap into our block? We  
could keep copying it by hand, but that's not much fun. We could add  
it to our block and then to the block archetype as well, or we can  
add it too cocoon-core. I've taken that last of these options locally.

sitemap-additions/cocoon-core-sitemap.xmap has been added. I honestly  
don't know where this should go. But leaving it only in cocoon-webapp  
strikes me as wrong.

Conclusions from Day 2:
It works! It works! Clearly the next steps are to add blocks but the  
sample demo code is running in my own archetype created block. Adding  
my own pipelines and flowscript from here should be reasonably simple.

Sadly the rest of my day will be taken up with meetings and  
preperations for meetings. So I leave you all with this till tomorrow.


View raw message