The other large part of the project at $WORK I’ve just finished was Cocoon. Cocoon is a Java web framework. It’s got some really neat ideas in it, and it’s main purpose in life is transforming XML. It is (or should be) a perfect match for XML databases.
I described Cocoon about a year ago, towards the start of this project. But how do I feel about it now? Looking back, was it the right choice?
To start with, I’m still very impressed with the core Cocoon technologies. The pipelines are perfect for dealing with XML. FlowScript still impresses the heck out of me.
But there’s a lot that leaves a sour taste. My first original complaint was about the size. Well, 50Mb isn’t so big. But the fact of the matter is that there’s an awful lot of stuff in there, quite a bit of which you don’t want to touch with a bargepole. We wasted a lot of time looking at things like XSP, Actions and implementing our own custom Generators. I wish I’d been made more aware of what FlowScript was up-front, and what it could do for more. I wish I’d realised that it’s basically the “C” in MVC.
Which dovetails straight into another complaint: documentation. There is quite a bit of documentation for Cocoon. But it’s still inadequate given the gargantuan size of the project. And the coverage is extremely spotty. Normally, I’d jump straight to the published literature, but the most recent Cocoon book I could find was hideously out of date. In fact, that’s what caused me to go down several of the rabbit-holes mentioned above.
When I’ve really needed to figure out what’s going on, I’ve invariable had to turn to the cocoon source code. Which due to it’s dependence on the weird-yet-not-wonderful avalon framework made it less than simple to understand.
My complaint about debugging still holds, although less severely. You get used to the seemingly-intractible error messages. You spot the patterns that are causing trouble. Like most things, logging goes a long way.
And then there’s Cocoon 2.2. My site was developed entirely on Cocoon 2.1. This certainly had it’s flaws—figuring out how to deploy it as a war file sensibly was a pain. But Cocoon 2.2 has Maven.
I’ve pointed out my dislike for Maven before. As have other people. Recently, other people in my office have been using it and I’ve witnessed the project overruns thanks to trying to figure out what Maven is doing. Nice idea, bad implementation.
Cocoon 2.2 uses Maven because it’s “modularized”. What this means is you can’t have a single project with everything in it any more. You have a “webapp” project and a “block” project. And when something changes you have to build the block, install it, build the webapp, mount the installed block in the webapp and fire up jetty. It doesn’t make for a good development environment.
Now I could be completely wrong and missing the obvious way to do seamless Cocoon 2.2 web development from with Eclipse. I’d love to be corrected. But for now, Cocoon 2.2 has shot itself in the foot as far as I’m concerned.
So I’m not happy with the future direction of Cocoon. I need to look again at why I chose it in the first place. Initially, it was because all the other web frameworks for Java (Struts, Tapestry, Wicket) all seemed totally focussed on form-based CRUD-style web apps. Cocoon focussed on documents and URLs instead. So it’s time to start working my way through the tutorials of the many java web frameworks in order to find a more suitable one. I may not find a good replacement for Cocoon. But I certainly need to try.
Update: In the comments, Grzegorz Kossakowski points out a screencast about the RCL which slightly lessens the pain of interactive development with Cocoon 2.2.
Jabbering Giraffe 
7 replies on “A Year in Cocoon”
Well, look what the cat just dragged in: The Craptaculous Web Framework.
Hi Dominic,
“Cocoon 2.2 uses Maven because it’s “modularized”. What this means is you can’t have a single project with everything in it any more. You have a “webapp” project and a “block” project. And when something changes you have to build the block, install it, build the webapp, mount the installed block in the webapp and fire up jetty. It doesn’t make for a good development environment.”
It’s common opinion about Cocoon 2.2 and it’s wrong by all means. This time I decided that I must do something to show that Cocoon 2.2 is easier than C2.1 and fun even if you don’t love Maven.
Being short on my free time I decided to make a short screencast which I put at this location: http://people.apache.org/~gkossakowski/cocoon-tutorial-rcl-2.html
Basically, it shows how Rapid Application Development is achieved with Cocoon 2.2. While watching it, notice that there are no restarts or redeployments; just straight hacking. 🙂
PS. I wanted to send you an e-mail but I have not found any place where I could find your e-mail address. It’s quite weird, IMHO…
Gregor, thanks for the tips. I really appreciate the guidance. I will take a closer look at that and review.
As to the mail address, that’s a damned good point and I’ll go fix that right now.
Gregor, I’ve finally gotten around to looking at the screencast for the rcl. Some comments:
Three lines for a maven archetype? That’s very confusing.
What the heck are all those warnings coming out of maven when you run it?
The maven plugin doesn’t set the M2_REPO CLASSPATH variable because it’s part of the workspace rather than part of the project. Perhaps if maven were less verbose, it could point this out and be noticed.
I did point this screencast out internally. My colleague mentioned that due to the custom
web.xmlhe was using, he couldn’t make use of the RCL. I didn’t attempt to verify this.But anyway, thanks for pointing the RCL. It makes life just that little bit easier.
Hmmm, another dissenter expresses points I missed.
Hi Dominic. My name is Grzegorz but I don’t mind calling me Gregor, though. 😉
Addressing your points:
1. I’m not sure what you find such confusing there. You just specify group/package (org.apache.cocoon) artifact’s name and version and finally group/package of your newly created application. If you have ideas how to reduce it and not loosing any of this information I’m sure Maven community is eager to hear you!
2. These warnings are coming from Velocity template processor and are completely harmless. I think it’s a bug in Maven’s archetype plug-in but I believe it could be worked around. Nobody had an itch strong enough to investigate it yet.
When it comes to custom web.xml, I believe there is a way to integrate it with RCL (haven’t used such feature myself). I think that it’s best to report such issues to our users mailing list so we can discuss possible solutions.
I only wonder how haven’t came across RCL. It’s mentioned in the tutorial “Your first Cocoon application using Maven 2” and I thought that’s quite expected that anyone starting with Cocoon 2.2 will read it.
At least I’m glad to see that you like RCL.
Sorry for the misnaming, Grzegorz. My English mind automatically dropped letters that didn’t seem right.
:-(The thing that troubles me with the archetype is that it’s three lines long. How on earth can I remember that? Particularly when maven gives me no help at all. I really don’t like having to rely on cut’n’paste the whole time.
The trouble with the warnings being harmless is that as a complete newcomer, I have no idea that they’re harmless. When I develop code, a warning from the compiler signals something that I really, really shouldn’t be doing unless I know what I’m up to. A warning emitted by default looks unprofessional and makes the user feel like they’ve done something wrong.
As to
web.xml, I’ll encourage my colleague to report the issue. Watching his restart times is starting to bug me and I don’t even sit next to him.;-)Why didn’t I know about RCL? Likely because I first looked at Cocoon 2.2 a long time ago and to be honest, Maven gave me such grief I didn’t get far enough figure out that RCL might be useful. Or perhaps I ignored it because I “knew” that I wanted to be able to deploy in tomcat in Eclipse. Anyway, I’ll take another look and try to get over my maven pain.