Step forward to today. Struts 1 is ubiquitous; nearly every Java Web Application Programmer has had some experience with Struts, building upon the base and working to create other Frameworks as well extend Struts1 into Struts2. Lately, I’ve been working with projects that consume a great deal of XML services and need to be available to many different viewing platforms in a coherent manner. Not only that, but there is a tremendous amount of conditional logic that must be matched depending upon input. Cocoon handles these things very well — it’s dispatch system allows for various URL matching which gives it’s configurations a very similar feel to a lightweight Business Rule engine. I decided to give it another shot and go through the tutorials and documentation — trying to evaluate whether or not it could fit into the way that my company does business.

I proceeded to find tutorials on the Cocoon Site, DeveloperWorks and other places. What I found was at best adequate, but at worst quite disappointing. The Cocoon Community insists that you download their source code and use their scripts tobuild it. Further, they don’t publish ANYWHERE what or how a file structure should be, and the various examples I found showed them to have no “best practices” within the community, let alone publish what these are. Further, all of the examples I found used Eclipse as the IDE and gave no information as to what to do in case you happen to use another favorite platform, say, IntelliJ. The best example I found used Maven/Jetty/Eclipse. It incorporated Spring and the latest build of Cocoon extremely well. Unfortunately if you’re not a Maven/Jetty/Eclipse house, it leaves no idea as to how to build your own system (YES, I DID use mvn idea:idea, still didn’t get what I wanted, in fact the mvn war:exploded didn’t help either).

I looked around for examples of how to build Cocoon from a root folder. I want to build it from the ground up, placing files, etc where they should be “in my opinion” so that I can integrate them with the way we do things around here (we still use Ant, for instance, and have our own way of creating projects for Idea that works for integrating builds with our platforms). Nothing exists, nowhere. The Cocoon mailing list goes so far as to say that they specifically WONT do this because they want people to get a deep dive into the entire project and all the available blocks. You can build a basic app from source at the Cocoon Site, but the war tasks to me were inadequate and I didn’t see the cool Spring Integration that the one really useful example offered. 10 days go by and still I’ve really never had a good debugger going in my IntelliJ with Cocoon, and the real, under-the-hood stuff that I seek just isn’t forthcoming.

I’ve even seen talk on the Cocoon Mailing lists that they plan to abandon Java and build the whole thing in Perl. Super, although I don’t know if this is real or just a few persons blowing off some steam.

Contrast this with Struts and Struts2. There are very clear road maps for both. Although I don’t agree with a lot of the integrations (especially JSF!!), Struts is, and continues to be, very easy to pick up, understand, extend and integrate with existing processes, software and builds. Although the Struts2 tutorials at this point are limited, and the number of books on Struts2 can be counted by a five-year-old, everything looks to be good going forward. I admire the WebWork integration and the way that the configurations have been cleaned up. I will definitely keep it in my Toolkit.

What do I think is better? Well, for it’s ability to match URLS, pass parameters, allow for non-reboot redeployments and presentation-agnostic capabilities, I would really feel that Cocoon, in a purist sense, is a superior platform. I can easily see complex integrations with A/B testing, Rule Engines and various view platforms working much easier in the Cocoon environment over Struts. I also believe that Cocoon offers some superior capabilities in the consumption of Web Services and other XML sources. I believe that REST is a better proposition with Cocoon. But I can’t recommend it for use in an ongoing Enterprise Environment because:

• There is too little documentation, and this documentation shrinks with newer releases.
• The Cocoon community is too fragmented and insulated.
• The Documentation is all over the place.
• There are no published “Best Practices”.
• It doesn’t easily integrate with disparate IDEs
• Nobody seems to want to share information to outsiders.

The Struts Community seems to be the opposite; Books are in several languages, plugins for the framework ship with most IDEs out of the box, and the community shares lovingly with anyone that wants to learn it. There is great documentation and many, many different answers for the same questions, allowing development organizations to pick and choose what’s right for them.

Cocoon is insular. There are many different plug-in “blocks” with solutions for problems, but the basics just aren’t covered well, and the “you must do it this way with these tools” attitude doesn’t play nice with organizations looking at their framework for long-term use. Resourcing is a big deal, and when I saw that my book had been published in India, I knew that Struts had won hands down over Cocoon, which really is, in my opinion, a better, but less organization-friendly, platform.

If I can finally figure out how to build Cocoon with Spring from a basic root folder without all the baggage that the Cocoon Developers’ Group insists on everyone using, I’ll share it because it might be worthwhile. If you don’t see it here after awhile, you know that I’ve moved on and found further investigation a waste of my time.