Ok,
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"
fe
http://cocoon.apache.org/2.2/core-modules/expression-language-impl/1.0/project-info.html
http://cocoon.apache.org/2.2/core-modules/store-impl/1.0/project-info.html
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(Response.java:972)
at org.mortbay.jetty.Response.reset(Response.java:921)
at
javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:193)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:574)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:544)
at
org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy5.service(Unknown Source)
at
org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:102)
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,
Romain.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
