cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gavin Carothers <ga...@versionthis.com>
Subject Creating a Block in Trunk, or Using Cocoon 2.2 Part I
Date Wed, 28 Jun 2006 21:18:39 GMT
To the Community:

Shall I keep up the blow by blow over the next few days or not? It  
seems to be me that people have been questioning if they can adopt  
2.2 for use in their applications or not. Personally I just want to  
try and see what happens and I thought others might want to see what  
it's like. At the end of this process I hope to come up with  
something a bit more organized as well.


Using Cocoon-2.2

Project Scope:
	Simple ReST style wrapper to an eXist database.
	Admin UI for eXist database.
	XSLT pipeline ending in XEP/FOP FO to PDF serializer
	
Currently written as a Cocoon-2.1.8 application. The application is  
being repurposed for a larger project and needs to be re-factored and  
as I have something working (the 2.1.8 app) that I can test the front  
end application vs  I have enough time to try out Cocoon 2.2. The  
2.1.8 application uses a few blocks directly.

Blocks:
webdav
javaflow
fop

All other dependancies and required blocks are indirect. As the Admin  
UI has not been written yet there is no template or forms block.


Wednesday, June 28th
svn co http://svn.apache.org/repos/asf/cocoon/tunk
mvn clean install

--build failure in  
org.apache.cocoon.components.expression.jexl.JexlTestCase --

Well, I'm not using jexl... yet. Lets see if we can't keep going.

mvn install -Dmaven.test.skip=true
	encountered 1 download failure and reran
	
tahdah! a war! and the Cocoon 2.2 Webapp Archetype have been built!

mvn cocoon:deploy

Question: is there a way to get maven2 to stop checking for updates  
from the remote repos and just use what I have installed?

Answer: mvn -o

result of quick non exhaustive test:
AJAX samples don't work so good
Flow samples work fine

Good enough to be going on with. Time to create a webapp.

mvn archetype:create -DarchetypeArtifactId=cocoon-22-archetype-webapp  
-DgroupId=com.amesondemand.bookbuild -DartifactId=tocmanager - 
DarchetypeGroupId=org.apache.cocoon -DarchetypeVersion=1.0.0-SNAPSHOT

mvn cocoon:deploy
mvn jetty6:run

Embedded error:  
org.apache.avalon.framework.configuration.ConfigurationException:  
Unable to read configurations from context://WEB-INF/sitemap-additions

Hrm, very close now... huh, my sitemap from src isn't being used at  
all that's strange. Okay, lets see the docs again. Oh! Shouldn't be  
creating a "webapp" I guess, trying to create block now.

mvn archetype:create -DarchetypeArtifactId=cocoon-22-archetype-block - 
DgroupId=com.amesondemand.bookbuild -DartifactId=toc-manager - 
DarchetypeGroupId=org.apache.cocoon -DarchetypeVersion=1.0.0-SNAPSHOT

Okay... interesting poms are rather similar, other then
<dependency>
   <groupId>org.apache.cocoon</groupId>
   <artifactId>cocoon-forms-impl</artifactId>
   <version>1.0.0-SNAPSHOT</version>
</dependency>
vs
<dependency>
   <groupId>org.apache.cocoon</groupId>
   <artifactId>cocoon-template-impl</artifactId>
   <version>1.0.0-SNAPSHOT</version>
</dependency>

however the source code layout is very different, rather then webapp  
we now have COB-INF and some demo spring code. Googling COB-INF  
assures me it has something to do with cocoon but no real idea what  
it is. Remember back to earlier conversions on the mailing list I  
think this is the chosen location for all cocoon configuration files  
in 2.2. That makes sense. Onward!

mvn -o cocoon:deploy

ah, nifty I get the same rapid deployment method I used to as the  
whole of COB-INF is mounted in the generated sitemap.xmap. This seems  
to be going much better then the "webapp" archetype, I can understand  
what's going on here for the most part. I haven't a clue how at some  
point I'm supposed to get a WAR out of this but that can wait. Lets  
see if I can start jetty and start writing some code!

mvn -o jetty6:run

bugger... that almost worked.

Embedded error:  
org.springframework.beans.factory.BeanDefinitionStoreException:  
Unexpected exception parsing XML document from resource loaded from  
byte array; nested exception is  
org.springframework.beans.factory.BeanDefinitionStoreException: Line  
18 in XML document from URL [file:/Users/gcarothers/Documents/ 
Programing/toc-manager/src/main/resources/META-INF/spring/demo- 
application-context.xml] is invalid; nested exception is  
org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration  
of element 'beans'.

Wait! I just saw cziegeler's post an hour or two ago about spring in  
cocoon.
http://www.osoco.org/archives/2006/06/cocoon_is_using.html  
NetNewsWire saves the day! Well I can't easily change the version of  
spring to depend on as that seems likely to break stuff and is a bit  
more involved then I want to get. So, lets see if removing the  
license works.

Victory! Cocoon is running!


short-lived...

No default type exists for 'map:pipeline' at file:/Users/gcarothers/ 
Documents/Programing/toc-manager/target/toc-manager/sitemap.xmap:23:19

I remember this being fixed I thought back in February, at least I  
thought I did. Oh well, try more in the morning.


Conclusions after Day 1 of Cocoon 2.2:
Hot spit, maven2 works with cocoon. Even with all the nasty stuff  
I've run into so far the build process has... sadly... saved me time  
over when I started using cocoon back with 2.1.3. The documentation  
in a few places on daisy is slightly out of date with what's in  
trunk. All in all it's MUCH nicer to work with 2.2 then it is with  
2.1... of course I haven't managed to run code yet ;)



Mime
View raw message