Cocoon has been around for years with an active development community. I tried to work with it in 2002 using the books and resources available at the time, but I was using Windows at that point and the books really focused more on a Unix/Linux deployment, and at the time I didn’t have the chops to really transfer this knowledge cleanly and was really never able to set up a coherent development environment for it. Struts, on the other hand, had the resources available to get up and running. Although the documentation wasn’t that great, I could “get home” on most issues, and when the level of frustration on completing some of the things that I needed to get done was at a boiling point, I did something about it and wrote a book with George Franciscus to share what I had learned with the larger community. I wasn’t alone with this either; many great books on the subject came out. As the framework diversified and solved many problems, so did the available web and print documentation from many wonderful people.
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.
Hello Danilo.
I’ll post a quick comment because I’m travelling now.
Thanks for sharing your well-balanced opinion. Although I would not agree with everything you said above, I think you got the point.
When it comes to documentation it has been restructured lately so it better reflects current state of Cocoon project.
I wonder which version of Cocoon you have tried 2.1 or 2.2. Starting from 2.2 you will not have to download Cocoon sources and build it in order to develop applications on top of Cocoon. Moreover, we have established standard directory layout for each application and we ship a Maven archetype that will create prototype ready for filling with application logic.
I would really like to see more detailed descriptions of your problems so I could give you some hints. Actaully, it would be the best if you could start a thread on Cocoon users’ mailing list.
Best regards,
Grzegorz
Danilo, you have many good and valid points. You line out Cocoon’s strengths and weaknesses really well. But at some points you’re just doing FUD:
- Struts vs. Cocoon:
Cocoon has never really competed with Struts. At the beginning it was more a documentation framework than a web application framework. There was hardly any serious support for form handling. Only with the rise of Cocoon Forms our self-conception changed. But still Cocoon is on a much broader base than Struts. Keeping Struts slim seems to be simple since it has a limited scope while we never got it managed to say: This is beyond Cocoon’s scope.
It’s probably valid though to compare Struts with Cocoon to a certain extent. But your point become worse:
- The Cocoon Community insists that you download their source code and use their scripts to build it:
You have to decide what you are writing about. Cocoon 2.1 based on Ant or Cocoon 2.2 based on Maven. For the first one the above is true, but many other of your points are not. For the second this statement is not true.
- [..] they plan to abandon Java and build the whole thing in Perl:
Yes, there was a thread titled Cocoon 2.3 may be in Perl lately. But first it was on the user list and initiated by a user. Second Perl was not mentioned once in the thread. How can you take that as serious hint for Cocoon moving to Perl?? Furthermore there is already a PHP framework called Popoon inspired by Cocoon – but it has nothing to do with our community.
- Nobody seems to want to share information to outsiders:
What the …? Where did you get this one from? I feel personally offended by such a statement. I have not done any major work with Cocoon since 2 years, I’m still active on the mailing lists though. And there are many developers answering user questions as well.
But back to your serious points:
Yes, Cocoon always lacked documentation or it was spread all over the place. Yes, Cocoon provides too many ways to get one thing done (e.g. database access). This also makes it hard to document it. Furthermore we are giving it a hard try to improve the documentation. We even refrained from announcing RC 1 of Cocoon 2.2 due to lack of documentation, but only announced RC 2 recently.
Besides that most of your points seems be in regard to the build system or deployment. Maven is that inflexible with fixed directory structures, it’s by design and intention to “standardize”. Maven lacks the integration with other IDEs and so on.
For us it was hard to maintain our own Ant-based build system and we decided to switch to Maven. Unfortunately, I can hardly imagine anything more harmful to an open source community than this process. Cocoon development was stuck for nearly a year. So many things are now different with Cocoon 2.2 than they used to be with 2.1. If it was a good choice at the end? I’m not convinced yet. I still hope that it pays out for us at one point.
Furthermore it’s hard for us to provide best practices without having enough experience ourselves. You must not forget that 2.2 is still not released while Struts 2 is out since more than a year.
“But at some points you’re just doing FUD:”
Well, I’m not promoting fear, but the uncertainty and doubt part is accurate.
Uncertainty because I don’t believe that I can integrate Cocoon into existing applications or build processes, let alone development environments without adopting everything I’m doing into the rigid build/deployment/development processes that Cocoon uses. We have 240,000 lines of code in an antiquated but adequate release system, and Since I can’t build Cocoon from a simple root folder and decide for myself or understand how files can be structured in my environments, Cocoon is useless.
Doubt, because I don’t see current articles on Cocoon; most are more than two years old. Also, I see no published best practices or complete end-to-end articles on getting up and running from ground zero. I think the lamest excuse for a tutorial is ‘download and build our source and run the examples.’ That is only slightly better than ‘just look at the code, it is self-documenting’.
“Cocoon has never really competed with Struts.”
Cocoon is an MVC framework, last time I checked. Maybe the word ‘compete’ is too harsh, but yet when I’ve been a on teams making decisions about frameworks, Struts and Cocoon seem to come up as choices — competing choices.
“But still Cocoon is on a much broader base than Struts. Keeping Struts slim seems to be simple since it has a limited scope while we never got it managed to say: This is beyond Cocoon’s scope”
This is a first for me. I’ve never heard of Struts being ‘slim’, in fact ‘bloated’ has popped up on more than one occasion. Cocoon has wonderful blocks and integrations and I feel that the themes for Cocoon’s development make perfect sense.
“they plan to abandon Java and build the whole thing in Perl:”
OK, this was a bit snarky, but to make a point, I read through the lists and the opinions were thick, like ‘ The cocoon-blank.war would lower the entry barriers I have to admit but this is not the aim. The aim is to have a quick start!’ — The author of that thread goes on to say that there are plenty of ways to view the code and build the examples as long as you do it in the way that is specified on the site.
“Nobody seems to want to share information to outsiders: — What the …? Where did you get this one from?”
In the paragraph above in this comment, there is an admission that the documentation is all over the place, incomplete and ‘hard’ to do. I have had difficult if not impossible luck searching the years of archives for answers on the Cocoon user’s list, and I’ve emailed participants for information concerning building the product from the root. There is actually no documentation anywhere that tells me what the core jar dependencies are for a blank cocoon “hello world” app, nor are any of the blocks documented with respect to their dependencies.
“Furthermore we are giving it a hard try to improve the documentation. We even refrained from announcing RC 1 of Cocoon 2.2 due to lack of documentation, but only announced RC 2 recently.”
Cocoon as a project has been around for YEARS. The fact that documentation is ‘hard’ is not really a good excuse. Professional developers are required and expected to fully document what they do and why they do it. The best amongst us can and will document what they were thinking when they wrote the code, and discuss how it might be extended. Hard, yes, but if something is to survive and make it at an enterprise level, documentation and flexibility is a must.
“Furthermore it’s hard for us to provide best practices without having enough experience ourselves. You must not forget that 2.2 is still not released while Struts 2 is out since more than a year.”
I still have yet to see best practices or complete documentation for earlier systems. Frankly, best practices will surface with more persons adopting and using Cocoon. I hope that in the future, I can see in the site:
A tutorial as good or better than the SpringMVC site. I want to build Cocoon, and even better, Cocoon/Spring from a root folder with absolutely zero dependencies on Eclipse, Ant, Maven, Jetty, etc. I would enjoy seeing articles on integration with these systems, but by tying them into the process, the issues get muddy.
A tutorial on Cocoon/Spring built in the same way. I believe that adoption of Cocoon would jump exponentially with a simple tutorial showing how these two fabulous frameworks can work together.
Documentation on Jar Dependencies for various builds, blocks, basic apps, etc.
I’m hopeful that Cocoon gets easier to build and learn, because I can’t wait for it to be easy enough for me to teach to my most junior engineers, and allow me to integrate it in POCs and eventual deployments. I believe that it has many advantages, and once the barriers to entry and education are lowered, it has a golden opportunity –
– Struts 1.x is pretty much at the end of the road, and there are many many competing frameworks that are trying to supplant it as the king of the hill. Cocoon represents one of these frameworks, and with the right effort it may emerge as something to really be proud of, instead of another framework among many that play second-banana. Here’s to hoping!
“I don’t believe that I can integrate Cocoon into existing applications or build processes, let alone development environments without adopting everything I’m doing into the rigid build/deployment/development processes that Cocoon uses.”
Actually I absolutely share your concerns. Maven seems to be an all-or-nothing thing: “You want to use a project that itself uses Maven? Build your own project with Maven!” – “But I have already a build system!?” – “Switch to Maven! It is easy.”
The promise of Maven is just to write a POM where you specify a dependency on Cocoon. That’s it. So yes, it might be easy. But that’s not the point.
My idea for integrating Cocoon into build processes would be to download the jars from the Maven repository. There are Ant tasks(http://maven.apache.org/ant-tasks.html) available from the Maven project that might help.
I’ll look into this. Jeorg, if you have a blog I’d be happy to put a link here. Enjoy your comments and the dialog…
“A tutorial as good or better than the SpringMVC site. I want to build Cocoon, and even better, Cocoon/Spring from a root folder with absolutely zero dependencies on Eclipse, Ant, Maven, Jetty, etc. I would enjoy seeing articles on integration with these systems, but by tying them into the process, the issues get muddy.”
Sorry, I really don’t understand your point here. How do you want to build (compile) such a big project as Cocoon is by not using any toolkit? Another question: why do you want to build Cocoon if binaries *are* shipped?
“A tutorial on Cocoon/Spring built in the same way. I believe that adoption of Cocoon would jump exponentially with a simple tutorial showing how these two fabulous frameworks can work together.
Documentation on Jar Dependencies for various builds, blocks, basic apps, etc.”
Cocoon-Spring integration in 2.2 is very tight and works very well. I think that there is not that much to write documentation on this topic as there is nothing special you need to do in order to use Spring while developing Cocoon applications.
When it comes to Jar dependencies, have you seen this:
“The ‘cocoon-core’ module is some kind of wrapper, that keeps all dependencies together in order to make it easier to use Cocoon as web application framework. For now the complete documentation of all core modules can be found in Cocoon core.”
(from http://cocoon.apache.org/2.2/core-modules/)
and this:
http://cocoon.apache.org/2.2/core-modules/core/2.2/dependencies.html
All dependencies needed for “Hello World” listed there. What’s more, all of them available at standard Maven’s repository so you could easily pull them all using few lines of scripting. This way you could eliminate Maven and integrate everything with your fancy build system.
I share Joerg’s opinion that some of your points are FUD.
“I share Joerg’s opinion that some of your points are FUD.”
Well, I expected flames for this. I’ll stand by my comments. Calling FUD at this point just makes my point — I’m not satisfied with what I’ve found and your argument that everything I need is available makes my point perfectly. It’s just not working for me the way that it is.
“Cocoon/Spring … I think that there is not that much to write documentation on this topic as there is nothing special you need to do in order to use Spring while developing Cocoon applications.”
Yeah, that explains why I can’t get a debugger running on it UNLESS I use the entire build system and Jetty in the article, and I can’t do it with IntelliJ cleanly and in the manner that I wish. Oh yeah, by the way, the ‘mvn war:war’ task is broken –> ‘no web.xml’.
The urls you mention are useful, but frankly after surfing your site for two weeks, I never ran across them before. Does that say anything about your documentation or organization? Throw me a bone. I didn’t write this article without putting a great deal of thought and effort into Cocoon. I am still doing so as I just bought the latest book I could find, hopefully giving me some new insight.
“How do you want to build (compile) such a big project as Cocoon is by not using any toolkit?”
No, I want to use MY TOOLKIT and my tools. I want to integrate Cocoon into MY enterprise environment, not the one specified by the Cocoon group. Building from a root folder and creating a build tree the way that I want it is more important to adoption than just downloading source, running the app and hacking away.
I understand that it’s much more sexy to keep developing a platform instead of addressing “FUD-dy-duddies” issues, but people like me make decisions on enterprise platforms, and I have bigger issues to address, like integration with existing platforms, resource skill-sets, time-to-market and learning curve. If you’re starting from a blank screen every time with a new application at a different company that you’re consulting for, that’s one thing, but out in the real world this type of luxury is extremely rare.
Comments addressing my concerns in a manner other than “we already have all this documentation and if you do everything our way you’ll be fine” is probably not going to win my further support, and also not get posted to this thread.
I know for a fact there’s more people like me out there. Perhaps a step back from the project, looking at its ‘adopt-ability’ with a jaundiced eye may reveal some insight. I don’t know.
I’m not trying to say that Cocoon sucks, because the opposite is true. I’m pleading for better tutorials and coherent documentation. Without the kind of path that other frameworks deliver in spades, Cocoon’s future isn’t safe, which is too damned bad because it really has way too many things going for it!
Danilo, let’s cool our discussion a little bit. I was too harsh but I felt somehow offended that you criticize Cocoon without asking for help on our mailing list thus not giving us a chance to become aware of all of this. Nevertheless I understand you, not everyone want to join a list at the very beginning when he has hardly anything working.
“Yeah, that explains why I can’t get a debugger running on it UNLESS I use the entire build system and Jetty in the article, and I can’t do it with IntelliJ cleanly and in the manner that I wish. Oh yeah, by the way, the ‘mvn war:war’ task is broken –> ‘no web.xml’.”
Unfortunately I don’t use IntelliJ but I believe some active committers do use so you could ask how to set up an environment and maybe add this information to our documentation.
When it comes to broken mvn war:war, which directory is the working one when you lunch this command?
“The urls you mention are useful, but frankly after surfing your site for two weeks, I never ran across them before. Does that say anything about your documentation or organization?”
Good question. I would like to hear your suggestions how to improve it. Usually it’s easier for someone outside the project to spot the weaknesses.
“No, I want to use MY TOOLKIT and my tools. I want to integrate Cocoon into MY enterprise environment, not the one specified by the Cocoon group. Building from a root folder and creating a build tree the way that I want it is more important to adoption than just downloading source, running the app and hacking away.”
I must admit that I don’t have experience with in-house development toolkits so it’s quite hard for me to give you tips. If you could elaborate a little bit on your requirements, problems and obstacles maybe we could come to some useful conclusions, I don’t know.
“I understand that it’s much more sexy to keep developing a platform instead of addressing “FUD-dy-duddies” issues, but people like me make decisions on enterprise platforms, and I have bigger issues to address, like integration with existing platforms, resource skill-sets, time-to-market and learning curve.”
Repeating myself but I want to make my point very clear: I promise to lend a hand as soon as you start asking for a help giving more details about your problems. Speaking for myself, it’s very sexy to help others playing with Cocoon.
I hope we can get back to arguments.
Thank you.
Yes, definitely escalated and for no good reason, especially since we’re really on the same side here.
There is absolutely nothing personal here; I think yours and Joerge’s opinions are extremely helpful and I feel comfortable asking the questions I think I need to have answered.
I will be very busy this week, but while I have some time I’ll compile a list of ideas/questions about what I’d like to do. From there we can see if we can make forward progress.
There is also a thread on the user list at the moment which goes into the same direction: http://marc.info/?t=119530014900006&r=1&w=4.
I just got the Cocoon Development book in the mail as well. Hopefully between all the information that is flying around we can reach get to a pleasant convergence of ideas, and hopefully help a lot of people and lower the barrier to entry in the process!
I think it’s very interesting how people “learn” with respect to programming languages, frameworks and the like. I’ve worked for years with people that could read JavaDocs and then just throw code out like they had been born with it in them. Others can hear a lecture or work with someone that knows it, and BAM, they’re off and running.
I’ve always picked things up with difficulty — Old school with books, yet I’ve always gained benefit with “typing out the code” along with the reading and running the examples. The JavaDocs and the like come later when I really want to refine what I know. That first mile is always the steepest for me.
Wow, I did not know I am wanted for claiming Cocoon 2.3 may be in Perl. Really, it’s small world. Well, I saw few posts with no answer and I need a way to grab attention. Apparently my voice was very loud and got me in trouble.
Commenting on what Danilo said about some people pick up quickly, yes, you are right. Some people pick quicker than other “In One of the learning Style”. For example, I am very slow when reading, because I have to stop every while and then and visualize what’s going on, so I learn quicker by vision. During my math courses, I could not understand any concept of solve any problem, even the smallest one, unless I draw them. I can not learning by listening. I failed all the courses that I attended the classes for. No, don’t get me wrong. The profs were great, but, not my way in learning. Some people get it easier by reading, and some people don’t get it in any way. Things that took me time and effort to learn, stuck with me for longer time. That’s why I am looking forward to learn Cocoon.
Speaking about Cocoon, it looks like it’s giving us some headache. I needed to understand every step I am going to take, exactly like what you needed. I had to blindly follow all the examples on the site, and then dig into the resulting components. The users on mailing list helped me a lot, especially when they realized that I can not use mvn at this point. Now I have a basic idea of how things work with Cocoon and I will move from here. I am working on a tutorial that will be found soon on wordpress.
One thhing may help you lot in understanding Cocoon, is if you think of it as a plat form that runs another application. So in order to create the simplest Cocoon application from scratch, you need to build the platform (which going to be the war), then you build the application and install it into the war.
I am trying to explain this in details on my new blog. The tutorials are not complete of course (not even close). I am planing to complete a level every week or so.
[...] December 2007 This is a very interesting article about using Apache Cocoon working, and how it compares to Struts and why. It is, first and [...]
Excellent explanation! I am slowly getting through the Cocoon book right now, and they too are explaining it in this manner — Currrently i’m working with some of the engineers on my team writing a ton af JavaScript, optimizing and refactoring it, and haven’t been able to devote the proper amount of time to really getting my arms wrapped around it.
I’m getting ready to launch a rant about my former BBF (Best Browser Forver) — FireFox. It seems that lately they’ve released some real turds for the Mac Leopard Platform — I’ve been using Safari more and more. I have only been using Firefox as a development tool, and in that role it reminds me of some of the early IntelliJ releases. Let’s hope they get their act together.