cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Slootmaekers <>
Subject Re: best wishes for 2008: 2.1 vs. 2.2
Date Sat, 29 Dec 2007 19:12:46 GMT
I can considered to be a novice user so I think my experiences are 
relevant here:
(when reading back what I wrote below, I might sound a bit cynic and 
chaotic, so be warned)

- installation: since I know maven, that was not too difficult. but I 
really don't like the fact that I get a +100MB repository just to tinker 
a bit with cocoon 2.2. this is too much for someone who just wants to 
play with it before you do real development. also, getting maven shoved 
down my throat is  not my idea of a good time (maven is really an awful 
build tool, really, the only thing you gain is that standardization 
saves you explicit configuration). But hey, all in all I was really 
surprised that just by following the instructions on the site, I got it 
working (no twiddling required).

- playing with examples: yes, the miniature examples (your first block, 
adding an extra block) on the site work, but that's it. the rest of them 
hasn't been ported from 2.1 yet and no, they don't work out of the box, 
they need minor twiddling.

- configuration: this is a complete disaster.

-- it is just too difficult to let the average web developer do it, or 
change it. So whenever a junior web developer needs something, you need 
the senior java guru come in, waste some time fighting various .xml 
config files before the "webbie" can continue. Thing here is that yes, 
you can figure it out, but what you'ld like to have is the documentation 
telling you what to do.

-- most of the cocoon sub projects have a site, but most of the sites 
just are a bunch of nice looking, empty, maven generated, pages.
for example:
"Core modules in detail"

now where are the details ?
Even when there is something there, it sometimes just does not work 
(Cocoon Authentication is such an example)
The advantage is that before you have discovered it just doesn't work 
with the given documentation , you have learned enough new tricks to 
solve other problems.

-- I had some legacy servlets I needed to use, it took me ages to 
discover I can set them up in servlet-service.xml instead of the usual 
j2ee web.xml ... no documentation about the collusion between the name 
of the block and the context-path parameter :(
I must admit here that my unhappiness here is also caused by j2ee 
standards that get interpreted differently by each and every application 
server out there. I haven't done the effort yet of trying to run my app 
with JBoss yet, but I'm certain I'll be fighting xml config files for 
more than a working day.

-- I would like the servlet functionality to be mapped using the site 
map (why else have a site map) but I still have to figure out how to do 
it. :( documentation does not cover this.

-- My application has a different mapping when running the "mvn 
jetty:run" way and as a .war file in the same jetty (the servlet mapping 
is different) :(
The thing here is that although strictly this might not be a cocoon 
problem but a jetty plugin problem or a spring configuration problem, 
the documentation is lacking. The only thing that is more or less 
correctly documented is the jetty-plugin.

--I still have from time to time Exceptions:
java.lang.IllegalStateException: Committed
        at org.mortbay.jetty.Response.resetBuffer(
        at org.mortbay.jetty.Response.reset(
        at $Proxy5.service(Unknown Source)
    As the application works, I can ignore it for know but again, I'm 
quite clueless as to what I'm doing wrong
    (maybe the request is given to the pipeline after the servlet has 
done its job, but that's just a guess)

-- half of the 2.2 documentation is none existing and using the 2.1 
documentation is fraud with danger as it sometimes works, sometimes not. 
Most of the misfits come of Classes that now have a different name or 
package, but it takes ages to figure that out.

- Architectural overview ?
didn't find any.

So the summary is,
cocoon might be great, but loosing half a day finding out where to add 2 
lines in a .xml file (problem is always: which .xml file and which 
lines) is no fun.
It might just be that the steep learning curve is just total lack of 
good documentation. And i'm pretty sure 90% of the developers just can't 
afford to waste so much time on trivial configuration stuff.

I'm sorry to have written such a negative mail, since I do believe in 
(what I think to be) the concept of cocoon.

have fun,


Ralph Goers wrote:
> My "wish" for Cocoon 2.2 has always been that
> 1. The "download" of Cocoon would be nothing more than installing a 
> maven plugin.
> 2. You'd use a Maven archetype to create a starter project. Ideally, 
> this is how the sample site should get created.
> 3. Building your project would automatically download the rest of 
> cocoon based upon the dependencies specified in the created project.
> 4. Building a project thus requires documentation on all the available 
> blocks, the services they provide, and how to invoke them.
> Unfortunately, I am still almost entirely focused on Cocoon 2.1 so I'm 
> not certain how close we have gotten to my wish, but I have a feeling 
> that if we can't do this today the effort to get there is pretty minimal.

> Ralph
> bart remmerie wrote:
>> Dear all,
>> During the past couple of months, I've been reading about "install 
>> issues" with cocoon 2.2 all the time.
>> There seem to be hardcore users, convinced that cocoon 2.2 is 
>> superior now that it's linked with maven and spring, ...
>> but there also are novice and/or less expert users, who are having a 
>> lot of problems with the new 2.2 configuration & installation.
>> Some years ago, the steep learning curve for cocoon was seen as one 
>> of the major problems to overcome while creating a larger user-base.
>> Shifting towards the integration with maven & spring doesn't simplify 
>> things.
>> Another issue was the lack of documentation... but in the past, the 
>> installation worked when you followed the instructions & you had a 
>> load of samples to get to know cocoon...
>> Now, cocoon seems to become so complicated that no-one has the time 
>> to document it properly.
>> Whatever the "hardcore" users may pretend, the perception of 
>> beginning user will define the evolution of cocoon.
>> Therefore my wishes for 2008:
>> listen to & learn from the novice users:
>> * simplify the installation & ease of use (in the perception of 
>> beginners)
>> * document your framework (in such a way that beginners consider it 
>> documented)
>> a little frustrated but hoping for the best,
>> Bart
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message