Questions and Answers from Part I:
"looking in the docs"
http://cocoon.zones.apache.org/daisy/documentation/g1/1159.html
refers to creating a block, but uses the cocoon-22-archetype-webapp
http://cocoon.zones.apache.org/daisy/documentation/g1/756.html
refers to a very strange archetype that happily no longer seems to exist
http://svn.apache.org/repos/asf/cocoon/whiteboard/example-apps/bricks-
archetype/
SEEMS to be based on the "webapp" archetype.
http://cocoon.zones.apache.org/daisy/documentation/863/g1/796.html
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
luck.
No default type exists for 'map:pipeline' at file:/Users/gcarothers/
Documents/Programing/toc-manager/target/toc-manager/sitemap.xmap:26:19
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.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114082894919896&w=2
removing
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-template-impl</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
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
luck.
No default type exists for 'map:pipeline' at file:/Users/gcarothers/
Documents/Programing/toc-manager/target/toc-manager/sitemap.xmap:23:19
There is another <beans/> file in cocoon-core-applicationContext.xml
lets see what removing it's license header does.
Nope.
Okay, lets look into the issues from February a bit more deeply.
Well, http://marc.theaimsgroup.com/?l=xml-cocoon-
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:
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-deployer-plugin-demo</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
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"?>
<demo>
<module>com.amesondemand.bookbuild:toc-manager</module>
<spring>This is a message coming from a Spring bean.</spring>
</demo>
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.
cocoon-2.2-dev/core/cocoon-core/src/main/resources/META-INF/legacy/
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.
Cheers,
Gavin
